> -----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. How was page fault > handled in stage1? If you meant PRI CAP that is not supported yet. However, Zhangfei is maintaining a branch to add support for devices that supports SMMUv3 STALL feature and handles S1 page fault. https://github.com/Linaro/qemu/commits/master-smmuv3-accel-v6/ Thanks, Shameer
