linux-kernel - Re: [PATCH v5 00/14] iommu/amd: Introduce Nested Translation support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c8a9e07a-b4dd-41f3-ac7d-0165349ebc61@amd.com>
Date: Thu, 15 Jan 2026 16:18:20 +0700
From: "Suthikulpanit, Suravee" <suravee.suthikulpanit@....com>
To: Jason Gunthorpe <jgg@...dia.com>, Nicolin Chen <nicolinc@...dia.com>
Cc: linux-kernel@...r.kernel.org, robin.murphy@....com, will@...nel.org,
 joro@...tes.org, kevin.tian@...el.com, jsnitsel@...hat.com,
 vasant.hegde@....com, iommu@...ts.linux.dev, santosh.shukla@....com,
 sairaj.arunkodilkar@....com, jon.grimm@....com, prashanthpra@...gle.com,
 wvw@...gle.com, wnliu@...gle.com, gptran@...gle.com, kpsingh@...gle.com,
 joao.m.martins@...cle.com, alejandro.j.jimenez@...cle.com
Subject: Re: [PATCH v5 00/14] iommu/amd: Introduce Nested Translation support



On 11/18/2025 12:54 AM, Jason Gunthorpe wrote:
> On Thu, Nov 13, 2025 at 01:52:02PM -0800, Nicolin Chen wrote:
>> On Wed, Nov 12, 2025 at 06:24:52PM +0000, Suravee Suthikulpanit wrote:
>>> Note: This series is rebased on top of:
>>>   * Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux.git
>>>     Branch: next
>>>     Commit: 91920a9d87f5 ("Merge branches 'arm/smmu/updates', 'arm/smmu/bindings',
>>>                            'mediatek', 'nvidia/tegra', 'amd/amd-vi' and 'core'
>>>                            into next")
>>>   * [PATCH v5] iommu/amd: Add support for hw_info for iommu capability query
>>>     https://lore.kernel.org/linux-iommu/20250926141901.511313-1-suravee.suthikulpanit@amd.com/T/#u
>>
>> Nit: this patch doesn't apply cleanly on 91920a9d87f5 :-/
>>
>>>   drivers/iommu/amd/Makefile          |   2 +-
>>>   drivers/iommu/amd/amd_iommu.h       |  36 ++++
>>>   drivers/iommu/amd/amd_iommu_types.h |  48 +++++-
>>>   drivers/iommu/amd/init.c            |   8 +
>>>   drivers/iommu/amd/iommu.c           | 221 +++++++++++++++---------
>>>   drivers/iommu/amd/iommufd.c         |  50 ++++++
>>>   drivers/iommu/amd/iommufd.h         |   5 +
>>>   drivers/iommu/amd/nested.c          | 259 ++++++++++++++++++++++++++++
>>>   include/uapi/linux/iommufd.h        |  11 ++
>>
>> So, this seems to be a preparatory series for AMD vIOMMU, yet it
>> doesn't properly work since it's missing IOMMUFD_VIOMMU_TYPE_AMD
>> and the invalidation component (HW_QUEUE).
>>
>> However, the series does declare IOMMU_HWPT_DATA_AMD_GUEST in the
>> uAPI header. I am afraid that might confuse user who might think
>> AMD now supports virtualization using the HWPT-based mode, like
>> Intel VT-d.
>>
>> So, maybe we should either:
>>    - leave a note at IOMMU_HWPT_DATA_AMD_GUEST to declare it is
>>      incomplete yet, and remove later
>>    - keep IOMMU_HWPT_DATA_AMD_GUEST in an AMD driver header, and
>>      move to the uAPI header later
>>
>> Jason?
> 
> Yeah, I like to see this incremental work, but Alex recently raised
> that we should be a bit more careful about how userspace perceives
> these partially complete things.
> 
> I don't think tricks with head files work well, I think what you'd
> want to do is leave some critical system call disabled until all the
> work is finished so the VMM never has to see a half working
> implementation?

Yes, this is a preparatory series for nested translation w/ AMD vIOMMU 
support. Currently, the amd_iommu_alloc_domain_nested() has not been 
hooked with the struct iommufd_viommu_ops.alloc_domain_nested. This is 
should prevent the nested domain usage until it is fully enabled in 
subsequent series, which will introduce the support for IOMMUFD vIOMMU 
for AMD.

I am working on preparing and sending out the next series.

Thanks,
Suravee

> The patch to get the info would have been a nice choice for this purpose..
> 
> Jason