netdev - Re: [PATCH 3/5] hyperv/IOMMU: Enable swiotlb bounce buffer for Isolation VM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211126074022.GA23659@lst.de>
Date:   Fri, 26 Nov 2021 08:40:22 +0100
From:   Christoph Hellwig <hch@....de>
To:     Tianyu Lan <ltykernel@...il.com>
Cc:     Christoph Hellwig <hch@....de>, dave.hansen@...ux.intel.com,
        luto@...nel.org, peterz@...radead.org, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, x86@...nel.org, hpa@...or.com,
        jgross@...e.com, sstabellini@...nel.org,
        boris.ostrovsky@...cle.com, kys@...rosoft.com,
        haiyangz@...rosoft.com, sthemmin@...rosoft.com, wei.liu@...nel.org,
        decui@...rosoft.com, joro@...tes.org, will@...nel.org,
        davem@...emloft.net, kuba@...nel.org, jejb@...ux.ibm.com,
        martin.petersen@...cle.com, m.szyprowski@...sung.com,
        robin.murphy@....com, xen-devel@...ts.xenproject.org,
        michael.h.kelley@...rosoft.com,
        Tianyu Lan <Tianyu.Lan@...rosoft.com>,
        iommu@...ts.linux-foundation.org, linux-hyperv@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
        netdev@...r.kernel.org, vkuznets@...hat.com, brijesh.singh@....com,
        konrad.wilk@...cle.com, parri.andrea@...il.com,
        thomas.lendacky@....com, dave.hansen@...el.com
Subject: Re: [PATCH 3/5] hyperv/IOMMU: Enable swiotlb bounce buffer for
 Isolation VM

On Wed, Nov 17, 2021 at 10:00:08PM +0800, Tianyu Lan wrote:
> On 11/17/2021 6:01 PM, Christoph Hellwig wrote:
>> This doesn't really have much to do with normal DMA mapping,
>> so why does this direct through the dma ops?
>>
>
> According to the previous discussion, dma_alloc_noncontigous()
> and dma_vmap_noncontiguous() may be used to handle the noncontigous
> memory alloc/map in the netvsc driver. So add alloc/free and vmap/vunmap
> callbacks here to handle the case. The previous patch v4 & v5 handles
> the allocation and map in the netvsc driver. If this should not go though 
> dma ops, We also may make it as vmbus specific function and keep
> the function in the vmbus driver.

But that only makes sense if they can actually use the normal DMA ops.
If you implement your own incomplete ops and require to use them you
do nothing but adding indirect calls to your fast path and making the
code convoluted.