On 2025/12/9 10:30, Duan, Zhenzhong wrote:
-----Original Message-----
From: Shameer Kolothum <[email protected]>
Subject: RE: [PATCH v6 00/33] hw/arm/virt: Add support for user-creatable
accelerated SMMUv3
-----Original Message-----
From: Duan, Zhenzhong <[email protected]>
Sent: 08 December 2025 10:08
To: Shameer Kolothum <[email protected]>; qemu-
[email protected]; [email protected]
Cc: [email protected]; [email protected]; Jason Gunthorpe
<[email protected]>; Nicolin Chen <[email protected]>;
[email protected];
[email protected]; Nathan Chen <[email protected]>; Matt Ochs
<[email protected]>; [email protected]; [email protected];
[email protected]; [email protected];
[email protected]; Liu, Yi L <[email protected]>; Krishnakant Jaju
<[email protected]>
Subject: RE: [PATCH v6 00/33] hw/arm/virt: Add support for user-creatable
accelerated SMMUv3
External email: Use caution opening links or attachments
Hi Shameer,
-----Original Message-----
From: Shameer Kolothum <[email protected]>
Subject: [PATCH v6 00/33] hw/arm/virt: Add support for user-creatable
accelerated SMMUv3
Hi,
Changes from v5:
https://lore.kernel.org/qemu-devel/20251031105005.24618-1-
skolothumtho
@nvidia.com/
- Addressed feedback from v5 and picked up R-by tags. Thanks to all!
- The previously split out _DSM fix mini-series is now accepted [0].
- Improved documentation about the rationale behind the design choice
of
returning an address space aliased to the system address space for
vfio-pci endpoint devices (patch #10).
- Added error propagation support for smmuv3_cmdq_consume() (patch
#13).
- Updated vSTE based HWPT installation to check the SMMU enabled case
(patch #14).
- Introduced an optional callback to PCIIOMMUOps to retrieve the MSI
doorbell GPA directly, allowing us to avoid unsafe page table walks for
MSI translation in accelerated SMMUv3 cases (patch #16).
- GBPA-based vSTE update depends on Nicolin's kernel patch [1].
- VFIO/IOMMUFD has dependency on Zhenzhong's patches: 4/5/8 from
the
pass-through support series [2].
PATCH organization:
1–26: Enables accelerated SMMUv3 with features based on default QEMU
SMMUv3,
including IORT RMR based MSI support.
27–29: Adds options for specifying RIL, ATS, and OAS features.
30–33: Adds PASID support, including VFIO changes.
Tests:
Performed basic sanity tests on an NVIDIA GRACE platform with GPU
device assignments. A CUDA test application was used to verify the SVA
use
case.
Further tests are always welcome.
I see PASID capability is exposed to guest but no pasid attachment in this
series.
Was the nested hwpt attached to SID instead of pasid?
In ARM world there is no specific PASID attachment. ARM uses a Context
Descriptor (CD) table indexed by PASID(substream in ARM) which is owned by
Guest. Hence, no specific PASID attach handling is required in QEMU.
I just realized a nested hwpt in ARM is “stage2 hwpt + guest CD table” rather
than
“stage2 hwpt + a guest s1 hwpt”. When creating nested hwpt, guest S1ContextPtr
is passed to host rather than a stage1 TTB. Do I understand right?
yeah. ARM SMMUv3 and AMD iommu does not attach pasid to host explicitly.
This should be done in the time of enabling nesting.
Regards,
Yi Liu
