When user does IOMMU_GET_HW_INFO ioctl, read the IOMMU control
register (MMIO offset 0x0018) and return it as part of
`struct iommu_hw_info_amd`.

Userspace can use this information to determine the features
supported by the underlying host kernel.

Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com>
---

The patch exposes the control register to the user space so that QEMU
can determine the list of features enabled by the host IOMMU driver
when there are passthrough devices. QEMU can use this information to
selectively enable the guest feature. One example of such feature is
enabling upto 2048 MSIs for passthrough devices. QEMU must not enable
this feature for passthrough devices when host IOMMU driver has not
enabled it.

The patch is based on top v6.17 (e5f0a698b34e) and patch [1] by Suravee

[1] https://lore.kernel.org/linux-iommu/20250926141901.511313-1-suravee.suthikulpanit@amd.com/

---

 drivers/iommu/amd/iommufd.c  | 3 +++
 include/uapi/linux/iommufd.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/iommu/amd/iommufd.c b/drivers/iommu/amd/iommufd.c
index 72eaaa923d04..83f34fc77ae8 100644
--- a/drivers/iommu/amd/iommufd.c
+++ b/drivers/iommu/amd/iommufd.c
@@ -12,6 +12,7 @@
 void *amd_iommufd_hw_info(struct device *dev, u32 *length, u32 *type)
 {
 	struct iommu_hw_info_amd *hwinfo;
+	struct amd_iommu *iommu = get_amd_iommu_from_dev(dev);
 
 	if (*type != IOMMU_HW_INFO_TYPE_DEFAULT &&
 	    *type != IOMMU_HW_INFO_TYPE_AMD)
@@ -26,6 +27,8 @@ void *amd_iommufd_hw_info(struct device *dev, u32 *length, u32 *type)
 
 	hwinfo->efr = amd_iommu_efr;
 	hwinfo->efr2 = amd_iommu_efr2;
+	hwinfo->control_register = readq(iommu->mmio_base
+					 + MMIO_CONTROL_OFFSET);
 
 	return hwinfo;
 }
diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
index efb52709c0a2..9435b2d877e7 100644
--- a/include/uapi/linux/iommufd.h
+++ b/include/uapi/linux/iommufd.h
@@ -637,6 +637,7 @@ struct iommu_hw_info_tegra241_cmdqv {
 struct iommu_hw_info_amd {
 	__aligned_u64 efr;
 	__aligned_u64 efr2;
+	__aligned_u64 control_register;
 };
 
 /**
-- 
2.34.1

On Wed, Oct 29, 2025 at 03:28:46PM +0530, Sairaj Kodilkar wrote:
> When user does IOMMU_GET_HW_INFO ioctl, read the IOMMU control
> register (MMIO offset 0x0018) and return it as part of
> `struct iommu_hw_info_amd`.
> 
> Userspace can use this information to determine the features
> supported by the underlying host kernel.
> 
> Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com>
> ---
> 
> The patch exposes the control register to the user space so that QEMU
> can determine the list of features enabled by the host IOMMU driver
> when there are passthrough devices. QEMU can use this information to
> selectively enable the guest feature. One example of such feature is
> enabling upto 2048 MSIs for passthrough devices. QEMU must not enable
> this feature for passthrough devices when host IOMMU driver has not
> enabled it.

Please document in the uapi header what bits are meaningful and
userspace can safely access..

You are OK that a 0 register means the kernel is old?

Jason

On 11/22/2025 5:05 AM, Jason Gunthorpe wrote:
> On Wed, Oct 29, 2025 at 03:28:46PM +0530, Sairaj Kodilkar wrote:
>> When user does IOMMU_GET_HW_INFO ioctl, read the IOMMU control
>> register (MMIO offset 0x0018) and return it as part of
>> `struct iommu_hw_info_amd`.
>>
>> Userspace can use this information to determine the features
>> supported by the underlying host kernel.
>>
>> Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com>
>> ---
>>
>> The patch exposes the control register to the user space so that QEMU
>> can determine the list of features enabled by the host IOMMU driver
>> when there are passthrough devices. QEMU can use this information to
>> selectively enable the guest feature. One example of such feature is
>> enabling upto 2048 MSIs for passthrough devices. QEMU must not enable
>> this feature for passthrough devices when host IOMMU driver has not
>> enabled it.
> Please document in the uapi header what bits are meaningful and
> userspace can safely access..
>
> You are OK that a 0 register means the kernel is old?

Yes. That's fine.
Please see 
https://lore.kernel.org/qemu-devel/20251118101532.4315-1-sarunkod@amd.com/
Here qemu uses the control register only to determine the 2K interrupt 
support and sets
corrosponding bits inside the virtual control register. Other bits in 
the virtual control
register are predefined and do not change even if the hardware control 
register is
returned as 0.

Thanks
Sairaj