Re: [BUG] iommu/dma: "Not yet supported" CC_SHARED rejection regresses dma_alloc_attrs() on SME hosts with IOMMU-attached GPUs (commit 8277a12d0d60)

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Timo Witte <timo.witte@gmail.com> writes:

> Commit 8277a12d0d60 ("dma-pool: track decrypted atomic pools and select
> them via attrs") added to iommu_dma_alloc():
>
>     /* Not yet supported */
>     if (is_alloc_cc_shared)
>         return NULL;
>


Is this the only hunk you had to remove?

>
> dma_alloc_attrs() auto-sets __DMA_ATTR_ALLOC_CC_SHARED whenever
> force_dma_unencrypted() is true. On an SME host (mem_encrypt=on) an AMD
> GPU with a 44-bit DMA mask hits that condition, so every GTT (system-RAM)
> allocation fails with NULL/-ENOMEM, amdgpu init aborts and the system
> boots without a display.
> IOMMU in Translated/DMA-FQ mode (iommu group 29).
>
> Before the mentioned patch it worked: the IOMMU PTE carries the SME C-bit,
> so the memory controller transparently decrypts for the device while pages
> stay
> encrypted at rest. For IOMMU-backed devices force_dma_unencrypted() is a
> false positive - the device DMA mask does not limit addressing once the
> IOMMU translates, so CC_SHARED should not be auto-set for them.
>
> When i remove the rejection and clear __DMA_ATTR_ALLOC_CC_SHARED
> in iommu_dma_alloc(), so encrypted pages are mapped with the C-bit and
> everything works again.
>
> Maybe we can implement real CC_SHARED support in the IOMMU path,
> so SEV + IOMMU works on x86?
>

Yes, this should be fixed in the IOMMU path.

>
> I already reported this in the amdgpu driver:
> https://gitlab.freedesktop.org/drm/amd/-/work_items/5735
> But i think it should be fixed in the iommu code as it's a regression.

-aneesh