Mostafa Saleh <[email protected]> writes:
> On Thu, May 14, 2026 at 08:13:25PM +0530, Aneesh Kumar K.V wrote:
>> >>
>> >> What I meant was that we need a generic way to identify a pKVM guest, so
>> >> that we can use it in the conditional above.
>> >
>> > I have this patch, with that I can boot with your series unmodified,
>> > but I will need to do more testing.
>> >
>>
>> Thanks, I can add this to the series once you complete the required testing.
>>
>
> I am still running more tests, but looking more into it. Setting
> force_dma_unencrypted() to true for pKVM guests is wrong, as the
> guest shouldn’t try to decrypt arbitrary memory as it can include
> sensitive information (for example in case of virtio sub-page
> allocation) and should strictly rely on the restricted-dma-pool
> for that.
>
> However, with my patch and setting force_dma_unencrypted() to false
> on top of this series, it fails on pKVM due to a missing shared
> attribute as Alexey mentioned, as now SWIOTLB rejects non shared
> attrs, so, the DMA-API has to pass it. With that, I can boot again:
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 5103a04df99f..b19aeec03f27 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -286,6 +286,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> }
>
> if (is_swiotlb_for_alloc(dev)) {
> + attrs |= DMA_ATTR_CC_SHARED;
> +
> page = dma_direct_alloc_swiotlb(dev, size, attrs);
> if (page) {
> /*
> @@ -449,6 +451,8 @@ struct page *dma_direct_alloc_pages(struct device *dev,
> size_t size,
> &cpu_addr, gfp, attrs);
>
> if (is_swiotlb_for_alloc(dev)) {
> + attrs |= DMA_ATTR_CC_SHARED;
> +
> page = dma_direct_alloc_swiotlb(dev, size, attrs);
> if (!page)
> return NULL;
> diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
> index 4e35264ab6f8..8ee5bbf78cfb 100644
> --- a/kernel/dma/direct.h
> +++ b/kernel/dma/direct.h
> @@ -92,6 +92,7 @@ static inline dma_addr_t dma_direct_map_phys(struct device
> *dev,
> if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
> return DMA_MAPPING_ERROR;
>
> + attrs |= DMA_ATTR_CC_SHARED;
> return swiotlb_map(dev, phys, size, dir, attrs);
> }
>
> --
>
How about the below?
modified kernel/dma/direct.c
@@ -278,6 +278,10 @@ void *dma_direct_alloc(struct device *dev, size_t size,
}
if (is_swiotlb_for_alloc(dev)) {
+
+ if (dev->dma_io_tlb_mem->unencrypted)
+ attrs |= DMA_ATTR_CC_SHARED;
+
page = dma_direct_alloc_swiotlb(dev, size, attrs);
if (page) {
/*
@@ -451,6 +455,10 @@ struct page *dma_direct_alloc_pages(struct device *dev,
size_t size,
&cpu_addr, gfp, attrs);
if (is_swiotlb_for_alloc(dev)) {
+
+ if (dev->dma_io_tlb_mem->unencrypted)
+ attrs |= DMA_ATTR_CC_SHARED;
+
page = dma_direct_alloc_swiotlb(dev, size, attrs);
if (!page)
return NULL;
modified kernel/dma/direct.h
@@ -92,6 +92,9 @@ static inline dma_addr_t dma_direct_map_phys(struct device
*dev,
if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
return DMA_MAPPING_ERROR;
+ if (dev->dma_io_tlb_mem->unencrypted)
+ attrs |= DMA_ATTR_CC_SHARED;
+
return swiotlb_map(dev, phys, size, dir, attrs);
}
>
>
> I will keep testing and let you know how it goes. If there is nothing
> else required to convert pKVM guests to CC, I can just post the patch
> separately as it has no dependency on this series.
>
That would be useful. I can then carry the patch as a dependent change,
which can also be merged separately
>
> Re force_dma_unencrypted(), I am looking into a safe way to use it
> for pKVM as I beleive it will be useful to eliminate some bouncing.
> However, that’s not critical for this series and can be added later
> as I am still investigating it, if I reach something I can post it
> along the pKVM patch above.
>
> Thanks,
> Mostafa
>
>>
>>
>> -aneesh
