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

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]

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

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]

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;
>
> 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.
>


This means that, with host memory encryption, DMA does not need to be
forced unencrypted when the device uses the IOMMU?

modified   arch/x86/mm/mem_encrypt.c
@@ -13,6 +13,7 @@
 #include <linux/cc_platform.h>
 #include <linux/mem_encrypt.h>
 #include <linux/virtio_anchor.h>
+#include <linux/iommu-dma.h>
 
 #include <asm/sev.h>
 
@@ -30,7 +31,7 @@ bool force_dma_unencrypted(struct device *dev)
 	 * device does not support DMA to addresses that include the
 	 * encryption mask.
 	 */
-	if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
+	if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) && !use_dma_iommu(dev)) {
 		u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
 		u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
 						dev->bus_dma_limit);


-aneesh

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

[Deucher, Alexander]

Public

> -----Original Message-----
> From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
> Sent: Wednesday, September 2, 2026 6:16 AM
> To: Timo Witte <timo.witte@gmail.com>; iommu@lists.linux.dev
> Cc: m.szyprowski@samsung.com; robin.murphy@arm.com;
> joro@8bytes.org; Deucher, Alexander <Alexander.Deucher@amd.com>
> Subject: Re: [BUG] iommu/dma: "Not yet supported" CC_SHARED rejection
> regresses dma_alloc_attrs() on SME hosts with IOMMU-attached GPUs
> (commit 8277a12d0d60)
>
> 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;
> >
> > 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.
> >
>
>
> This means that, with host memory encryption, DMA does not need to be
> forced unencrypted when the device uses the IOMMU?

+ Tom and Vasant.

Yes, otherwise most devices won't be able to work with encrypted memory since most devices don't support a DMA mask large enough to cover the C bit.

Alex

>
> modified   arch/x86/mm/mem_encrypt.c
> @@ -13,6 +13,7 @@
>  #include <linux/cc_platform.h>
>  #include <linux/mem_encrypt.h>
>  #include <linux/virtio_anchor.h>
> +#include <linux/iommu-dma.h>
>
>  #include <asm/sev.h>
>
> @@ -30,7 +31,7 @@ bool force_dma_unencrypted(struct device *dev)
>        * device does not support DMA to addresses that include the
>        * encryption mask.
>        */
> -     if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
> +     if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) &&
> !use_dma_iommu(dev))
> +{
>               u64 dma_enc_mask =
> DMA_BIT_MASK(__ffs64(sme_me_mask));
>               u64 dma_dev_mask = min_not_zero(dev-
> >coherent_dma_mask,
>                                               dev->bus_dma_limit);
>
>
> -aneesh

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

[Marek Szyprowski]

On 02.09.2026 20:26, Deucher, Alexander wrote:
>> -----Original Message-----
>> From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
>> Sent: Wednesday, September 2, 2026 6:16 AM
>> To: Timo Witte <timo.witte@gmail.com>; iommu@lists.linux.dev
>> Cc: m.szyprowski@samsung.com; robin.murphy@arm.com;
>> joro@8bytes.org; Deucher, Alexander <Alexander.Deucher@amd.com>
>> Subject: Re: [BUG] iommu/dma: "Not yet supported" CC_SHARED rejection
>> regresses dma_alloc_attrs() on SME hosts with IOMMU-attached GPUs
>> (commit 8277a12d0d60)
>>
>> 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;
>>>
>>> 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.
>>>
>>
>> This means that, with host memory encryption, DMA does not need to be
>> forced unencrypted when the device uses the IOMMU?
> + Tom and Vasant.
>
> Yes, otherwise most devices won't be able to work with encrypted memory since most devices don't support a DMA mask large enough to cover the C bit.
Is this the proper fix/workaround for v7.3-rc? If so, then Aneesh, please
send it as a complete patch so I will take it to the dma-mapping-fixes.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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]

Marek Szyprowski <m.szyprowski@samsung.com> writes:

> On 02.09.2026 20:26, Deucher, Alexander wrote:
>>> -----Original Message-----
>>> From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
>>> Sent: Wednesday, September 2, 2026 6:16 AM
>>> To: Timo Witte <timo.witte@gmail.com>; iommu@lists.linux.dev
>>> Cc: m.szyprowski@samsung.com; robin.murphy@arm.com;
>>> joro@8bytes.org; Deucher, Alexander <Alexander.Deucher@amd.com>
>>> Subject: Re: [BUG] iommu/dma: "Not yet supported" CC_SHARED rejection
>>> regresses dma_alloc_attrs() on SME hosts with IOMMU-attached GPUs
>>> (commit 8277a12d0d60)
>>>
>>> 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;
>>>>
>>>> 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.
>>>>
>>>
>>> This means that, with host memory encryption, DMA does not need to be
>>> forced unencrypted when the device uses the IOMMU?
>> + Tom and Vasant.
>>
>> Yes, otherwise most devices won't be able to work with encrypted memory since most devices don't support a DMA mask large enough to cover the C bit.
>
> Is this the proper fix/workaround for v7.3-rc? If so, then Aneesh, please
> send it as a complete patch so I will take it to the dma-mapping-fixes.
>


I am still waiting for testing feedback. I sent a reminder on Friday.

-aneesh

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

[Timo Witte]

I tried out the fix and it resolved the issue for me. A clean boot
shows no problems with the GPU which does DMA with encrypted memory.

Environment:
- AMD platform with SME enabled (mem_encrypt=on)
- AMD GPU with a 44-bit DMA mask behind the AMD IOMMU (translated / DMA-FQ
  mode, iommu group 29)

Thanks a lot,
Timo


On Mon, Sep 7, 2026 at 3:55 PM Aneesh Kumar K.V <aneesh.kumar@kernel.org> wrote:
>
> Marek Szyprowski <m.szyprowski@samsung.com> writes:
>
> > On 02.09.2026 20:26, Deucher, Alexander wrote:
> >>> -----Original Message-----
> >>> From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
> >>> Sent: Wednesday, September 2, 2026 6:16 AM
> >>> To: Timo Witte <timo.witte@gmail.com>; iommu@lists.linux.dev
> >>> Cc: m.szyprowski@samsung.com; robin.murphy@arm.com;
> >>> joro@8bytes.org; Deucher, Alexander <Alexander.Deucher@amd.com>
> >>> Subject: Re: [BUG] iommu/dma: "Not yet supported" CC_SHARED rejection
> >>> regresses dma_alloc_attrs() on SME hosts with IOMMU-attached GPUs
> >>> (commit 8277a12d0d60)
> >>>
> >>> 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;
> >>>>
> >>>> 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.
> >>>>
> >>>
> >>> This means that, with host memory encryption, DMA does not need to be
> >>> forced unencrypted when the device uses the IOMMU?
> >> + Tom and Vasant.
> >>
> >> Yes, otherwise most devices won't be able to work with encrypted memory since most devices don't support a DMA mask large enough to cover the C bit.
> >
> > Is this the proper fix/workaround for v7.3-rc? If so, then Aneesh, please
> > send it as a complete patch so I will take it to the dma-mapping-fixes.
> >
>
>
> I am still waiting for testing feedback. I sent a reminder on Friday.
>
> -aneesh

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

[Vasant Hegde]

On 9/2/2026 11:56 PM, Deucher, Alexander wrote:
> Public
> 
>> -----Original Message-----
>> From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
>> Sent: Wednesday, September 2, 2026 6:16 AM
>> To: Timo Witte <timo.witte@gmail.com>; iommu@lists.linux.dev
>> Cc: m.szyprowski@samsung.com; robin.murphy@arm.com;
>> joro@8bytes.org; Deucher, Alexander <Alexander.Deucher@amd.com>
>> Subject: Re: [BUG] iommu/dma: "Not yet supported" CC_SHARED rejection
>> regresses dma_alloc_attrs() on SME hosts with IOMMU-attached GPUs
>> (commit 8277a12d0d60)
>>
>> 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;
>>>
>>> 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.
>>>
>>
>>
>> This means that, with host memory encryption, DMA does not need to be
>> forced unencrypted when the device uses the IOMMU?
> 
> + Tom and Vasant.
> 
> Yes, otherwise most devices won't be able to work with encrypted memory since most devices don't support a DMA mask large enough to cover the C bit.

Right. With SME, currently AMD IOMMU driver always sets C-bit (encryption bit)
in IOMMU page table.

-Vasant

> 
> Alex
> 
>>
>> modified   arch/x86/mm/mem_encrypt.c
>> @@ -13,6 +13,7 @@
>>  #include <linux/cc_platform.h>
>>  #include <linux/mem_encrypt.h>
>>  #include <linux/virtio_anchor.h>
>> +#include <linux/iommu-dma.h>
>>
>>  #include <asm/sev.h>
>>
>> @@ -30,7 +31,7 @@ bool force_dma_unencrypted(struct device *dev)
>>        * device does not support DMA to addresses that include the
>>        * encryption mask.
>>        */
>> -     if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
>> +     if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) &&
>> !use_dma_iommu(dev))
>> +{
>>               u64 dma_enc_mask =
>> DMA_BIT_MASK(__ffs64(sme_me_mask));
>>               u64 dma_dev_mask = min_not_zero(dev-
>>> coherent_dma_mask,
>>                                               dev->bus_dma_limit);
>>
>>
>> -aneesh

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

[Timo Witte]

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;

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?

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.

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

[Mostafa Saleh]

On Tue, Sep 01, 2026 at 11:09:03PM +0200, Timo Witte wrote:
> 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;
> 
> 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?

I believe that is the way forward, but as the merge window is closed
it won't be possible to land something that big in 7.3, we would
need a fix for the regression for now.

I think your suggestion works be clearing the __DMA_ATTR_ALLOC_CC_SHARED
from iommu_dma_alloc() but no need to remove the rejection then.

Otherwise, force_dma_unencrypted() can check something as
use_dma_iommu() but that feels like the wrong place, as the HW does
need to decrypt the memory and dma-iommu would be the one knowing
how to do that.

So, I'd suggest you send a patch with your fix.

Thanks,
Mostafa

> 
> 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.
>