On 11/26/2021 3:40 PM, Christoph Hellwig wrote:
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
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
On 11/17/2021 10:00 PM, 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
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
On 11/17/2021 3:12 AM, Borislav Petkov wrote:
What you should do, instead, is add an isol. VM specific
hv_cc_platform_has() just like amd_cc_platform_has() and handle
the cc_attrs there for your platform, like return false for
CC_ATTR_GUEST_MEM_ENCRYPT and then you won't need to add that hv_*
This doesn't really have much to do with normal DMA mapping,
so why does this direct through the dma ops?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
