IOMMU regression in linux-6.18.y

IOMMU regression in linux-6.18.y

[Mario Limonciello]

Hi,

Recently I found out that amdxdna stopped working in linux-6.18.4.  This 
is because of this commit in linux-6.18.y:

commit c341dee80b5d ("iommu: disable SVA when CONFIG_X86 is set")

That was originally backported from upstream:

commit 72f98ef9a4be ("iommu: disable SVA when CONFIG_X86 is set")

---

SVA support is a requirement for amdxdna.

The series that this commit came from was part of a larger 8 patch 
series, but this was the only commit that was CC'ed to stable.

As a result this is not broken in 6.19-rc, but it is broken in 
linux-6.18.y (and presumably any older stable kernels still around that 
picked it up).

So there are two options I see:

1) Revert c341dee80b5d in linux-6.18.y (and any other stable kernel that 
picked it up but has amdxdna)

2) Bring the entire 8 patch series to linux-6.18.y.

This is the entire series (I didn't look up the hashes from mainline, 
but they should have all landed):
https://lore.kernel.org/linux-iommu/20251022082635.2462433-1-baolu.lu@linux.intel.com/

What should we do?

Re: IOMMU regression in linux-6.18.y

[Mario Limonciello]

On 1/20/26 8:08 PM, Mario Limonciello wrote:
> Hi,
> 
> Recently I found out that amdxdna stopped working in linux-6.18.4.  This 
> is because of this commit in linux-6.18.y:
> 
> commit c341dee80b5d ("iommu: disable SVA when CONFIG_X86 is set")
> 
> That was originally backported from upstream:
> 
> commit 72f98ef9a4be ("iommu: disable SVA when CONFIG_X86 is set")
> 
> ---
> 
> SVA support is a requirement for amdxdna.
> 
> The series that this commit came from was part of a larger 8 patch 
> series, but this was the only commit that was CC'ed to stable.
> 
> As a result this is not broken in 6.19-rc, but it is broken in 
> linux-6.18.y (and presumably any older stable kernels still around that 
> picked it up).
> 
> So there are two options I see:
> 
> 1) Revert c341dee80b5d in linux-6.18.y (and any other stable kernel that 
> picked it up but has amdxdna)
> 
> 2) Bring the entire 8 patch series to linux-6.18.y.
> 
> This is the entire series (I didn't look up the hashes from mainline, 
> but they should have all landed):
> https://lore.kernel.org/linux-iommu/20251022082635.2462433-1- 
> baolu.lu@linux.intel.com/
> 
> What should we do?
> 

If the decision is to take the remaining commits to 6.18.y to fix this I 
did confirm they cleanly cherry pick and build.  Here are the hashes.

commit 27bfafac65d8 ("mm: add a ptdesc flag to mark kernel page tables")
commit 977870522af3 ("mm: actually mark kernel page table pages")
commit 412d000346ea ("x86/mm: use 'ptdesc' when freeing PMD pages")
commit 018942956723 ("mm: introduce pure page table freeing function")
commit bf9e4e30f353 ("x86/mm: use pagetable_free()")
commit 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page 
tables")
commit e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for 
kernel address space")

Re: IOMMU regression in linux-6.18.y

[Baolu Lu]

On 1/21/26 13:26, Mario Limonciello wrote:
> 
> 
> On 1/20/26 8:08 PM, Mario Limonciello wrote:
>> Hi,
>>
>> Recently I found out that amdxdna stopped working in linux-6.18.4.  
>> This is because of this commit in linux-6.18.y:
>>
>> commit c341dee80b5d ("iommu: disable SVA when CONFIG_X86 is set")
>>
>> That was originally backported from upstream:
>>
>> commit 72f98ef9a4be ("iommu: disable SVA when CONFIG_X86 is set")
>>
>> ---
>>
>> SVA support is a requirement for amdxdna.
>>
>> The series that this commit came from was part of a larger 8 patch 
>> series, but this was the only commit that was CC'ed to stable.
>>
>> As a result this is not broken in 6.19-rc, but it is broken in 
>> linux-6.18.y (and presumably any older stable kernels still around 
>> that picked it up).
>>
>> So there are two options I see:
>>
>> 1) Revert c341dee80b5d in linux-6.18.y (and any other stable kernel 
>> that picked it up but has amdxdna)
>>
>> 2) Bring the entire 8 patch series to linux-6.18.y.
>>
>> This is the entire series (I didn't look up the hashes from mainline, 
>> but they should have all landed):
>> https://lore.kernel.org/linux-iommu/20251022082635.2462433-1- 
>> baolu.lu@linux.intel.com/
>>
>> What should we do?
>>
> 
> If the decision is to take the remaining commits to 6.18.y to fix this I 
> did confirm they cleanly cherry pick and build.  Here are the hashes.
> 
> commit 27bfafac65d8 ("mm: add a ptdesc flag to mark kernel page tables")
> commit 977870522af3 ("mm: actually mark kernel page table pages")
> commit 412d000346ea ("x86/mm: use 'ptdesc' when freeing PMD pages")
> commit 018942956723 ("mm: introduce pure page table freeing function")
> commit bf9e4e30f353 ("x86/mm: use pagetable_free()")
> commit 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page 
> tables")
> commit e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for 
> kernel address space")
> 

Yes. These patches fix a security issue in iommu/sva on x86 and restore
the SVA functionality.

Thanks,
baolu

Re: IOMMU regression in linux-6.18.y

[Greg KH]

On Wed, Jan 21, 2026 at 03:14:42PM +0800, Baolu Lu wrote:
> On 1/21/26 13:26, Mario Limonciello wrote:
> > 
> > 
> > On 1/20/26 8:08 PM, Mario Limonciello wrote:
> > > Hi,
> > > 
> > > Recently I found out that amdxdna stopped working in linux-6.18.4.
> > > This is because of this commit in linux-6.18.y:
> > > 
> > > commit c341dee80b5d ("iommu: disable SVA when CONFIG_X86 is set")
> > > 
> > > That was originally backported from upstream:
> > > 
> > > commit 72f98ef9a4be ("iommu: disable SVA when CONFIG_X86 is set")
> > > 
> > > ---
> > > 
> > > SVA support is a requirement for amdxdna.
> > > 
> > > The series that this commit came from was part of a larger 8 patch
> > > series, but this was the only commit that was CC'ed to stable.
> > > 
> > > As a result this is not broken in 6.19-rc, but it is broken in
> > > linux-6.18.y (and presumably any older stable kernels still around
> > > that picked it up).
> > > 
> > > So there are two options I see:
> > > 
> > > 1) Revert c341dee80b5d in linux-6.18.y (and any other stable kernel
> > > that picked it up but has amdxdna)
> > > 
> > > 2) Bring the entire 8 patch series to linux-6.18.y.
> > > 
> > > This is the entire series (I didn't look up the hashes from
> > > mainline, but they should have all landed):
> > > https://lore.kernel.org/linux-iommu/20251022082635.2462433-1-
> > > baolu.lu@linux.intel.com/
> > > 
> > > What should we do?
> > > 
> > 
> > If the decision is to take the remaining commits to 6.18.y to fix this I
> > did confirm they cleanly cherry pick and build.  Here are the hashes.
> > 
> > commit 27bfafac65d8 ("mm: add a ptdesc flag to mark kernel page tables")
> > commit 977870522af3 ("mm: actually mark kernel page table pages")
> > commit 412d000346ea ("x86/mm: use 'ptdesc' when freeing PMD pages")
> > commit 018942956723 ("mm: introduce pure page table freeing function")
> > commit bf9e4e30f353 ("x86/mm: use pagetable_free()")
> > commit 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page
> > tables")
> > commit e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for
> > kernel address space")
> > 
> 
> Yes. These patches fix a security issue in iommu/sva on x86 and restore
> the SVA functionality.

So all should be backported?  If so, great, but why were they not tagged
as such?

thanks,

greg k-h

Re: IOMMU regression in linux-6.18.y

[Baolu Lu]

On 1/21/26 15:26, Greg KH wrote:
> On Wed, Jan 21, 2026 at 03:14:42PM +0800, Baolu Lu wrote:
>> On 1/21/26 13:26, Mario Limonciello wrote:
>>>
>>>
>>> On 1/20/26 8:08 PM, Mario Limonciello wrote:
>>>> Hi,
>>>>
>>>> Recently I found out that amdxdna stopped working in linux-6.18.4.
>>>> This is because of this commit in linux-6.18.y:
>>>>
>>>> commit c341dee80b5d ("iommu: disable SVA when CONFIG_X86 is set")
>>>>
>>>> That was originally backported from upstream:
>>>>
>>>> commit 72f98ef9a4be ("iommu: disable SVA when CONFIG_X86 is set")
>>>>
>>>> ---
>>>>
>>>> SVA support is a requirement for amdxdna.
>>>>
>>>> The series that this commit came from was part of a larger 8 patch
>>>> series, but this was the only commit that was CC'ed to stable.
>>>>
>>>> As a result this is not broken in 6.19-rc, but it is broken in
>>>> linux-6.18.y (and presumably any older stable kernels still around
>>>> that picked it up).
>>>>
>>>> So there are two options I see:
>>>>
>>>> 1) Revert c341dee80b5d in linux-6.18.y (and any other stable kernel
>>>> that picked it up but has amdxdna)
>>>>
>>>> 2) Bring the entire 8 patch series to linux-6.18.y.
>>>>
>>>> This is the entire series (I didn't look up the hashes from
>>>> mainline, but they should have all landed):
>>>> https://lore.kernel.org/linux-iommu/20251022082635.2462433-1-
>>>> baolu.lu@linux.intel.com/
>>>>
>>>> What should we do?
>>>>
>>>
>>> If the decision is to take the remaining commits to 6.18.y to fix this I
>>> did confirm they cleanly cherry pick and build.  Here are the hashes.
>>>
>>> commit 27bfafac65d8 ("mm: add a ptdesc flag to mark kernel page tables")
>>> commit 977870522af3 ("mm: actually mark kernel page table pages")
>>> commit 412d000346ea ("x86/mm: use 'ptdesc' when freeing PMD pages")
>>> commit 018942956723 ("mm: introduce pure page table freeing function")
>>> commit bf9e4e30f353 ("x86/mm: use pagetable_free()")
>>> commit 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page
>>> tables")
>>> commit e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for
>>> kernel address space")
>>>
>>
>> Yes. These patches fix a security issue in iommu/sva on x86 and restore
>> the SVA functionality.
> 
> So all should be backported?  If so, great, but why were they not tagged
> as such?

Yes, they should be backported. I am sorry; we should have tagged them
at the time we upstreamed them.

> 
> thanks,
> 
> greg k-h
> 

Thanks,
baolu

Re: IOMMU regression in linux-6.18.y

[Greg KH]

On Wed, Jan 21, 2026 at 03:32:42PM +0800, Baolu Lu wrote:
> On 1/21/26 15:26, Greg KH wrote:
> > On Wed, Jan 21, 2026 at 03:14:42PM +0800, Baolu Lu wrote:
> > > On 1/21/26 13:26, Mario Limonciello wrote:
> > > > 
> > > > 
> > > > On 1/20/26 8:08 PM, Mario Limonciello wrote:
> > > > > Hi,
> > > > > 
> > > > > Recently I found out that amdxdna stopped working in linux-6.18.4.
> > > > > This is because of this commit in linux-6.18.y:
> > > > > 
> > > > > commit c341dee80b5d ("iommu: disable SVA when CONFIG_X86 is set")
> > > > > 
> > > > > That was originally backported from upstream:
> > > > > 
> > > > > commit 72f98ef9a4be ("iommu: disable SVA when CONFIG_X86 is set")
> > > > > 
> > > > > ---
> > > > > 
> > > > > SVA support is a requirement for amdxdna.
> > > > > 
> > > > > The series that this commit came from was part of a larger 8 patch
> > > > > series, but this was the only commit that was CC'ed to stable.
> > > > > 
> > > > > As a result this is not broken in 6.19-rc, but it is broken in
> > > > > linux-6.18.y (and presumably any older stable kernels still around
> > > > > that picked it up).
> > > > > 
> > > > > So there are two options I see:
> > > > > 
> > > > > 1) Revert c341dee80b5d in linux-6.18.y (and any other stable kernel
> > > > > that picked it up but has amdxdna)
> > > > > 
> > > > > 2) Bring the entire 8 patch series to linux-6.18.y.
> > > > > 
> > > > > This is the entire series (I didn't look up the hashes from
> > > > > mainline, but they should have all landed):
> > > > > https://lore.kernel.org/linux-iommu/20251022082635.2462433-1-
> > > > > baolu.lu@linux.intel.com/
> > > > > 
> > > > > What should we do?
> > > > > 
> > > > 
> > > > If the decision is to take the remaining commits to 6.18.y to fix this I
> > > > did confirm they cleanly cherry pick and build.  Here are the hashes.
> > > > 
> > > > commit 27bfafac65d8 ("mm: add a ptdesc flag to mark kernel page tables")
> > > > commit 977870522af3 ("mm: actually mark kernel page table pages")
> > > > commit 412d000346ea ("x86/mm: use 'ptdesc' when freeing PMD pages")
> > > > commit 018942956723 ("mm: introduce pure page table freeing function")
> > > > commit bf9e4e30f353 ("x86/mm: use pagetable_free()")
> > > > commit 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page
> > > > tables")
> > > > commit e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for
> > > > kernel address space")
> > > > 
> > > 
> > > Yes. These patches fix a security issue in iommu/sva on x86 and restore
> > > the SVA functionality.
> > 
> > So all should be backported?  If so, great, but why were they not tagged
> > as such?
> 
> Yes, they should be backported. I am sorry; we should have tagged them
> at the time we upstreamed them.

Ok, all now queued up, thanks.

greg k-h