Sorry for a late reply. On Wed, May 28, 2025 at 07:12:25AM +0000, Duan, Zhenzhong wrote: > >Third, the vSMMU model, for invalidation efficiency and HW Queue > >support, isolates all emulated devices out of the nesting-enabled > >vSMMU instance, suggested by Jason. So, only passthrough devices > >would use the nesting-enabled vSMMU instance, meaning there is no > >need of IOMMU_NOTIFIER_IOTLB_EVENTS: > > I see, then you need to check if there is emulated device under > nesting-enabled vSMMU and fail if there is.
Shameer is working on a multi-vSMMU model in the QEMU. This gives each VM different instances to attach devices. And we do not plan to support emulated devices on an nesting enabled vSMMU instance, which is a bit different than the VT-d model. > >On the other hand, the VT-d model is a bit different. It's a giant > >vIOMMU for all devices (either passthrough or emualted). For all > >emulated devices, it needs IOMMU_NOTIFIER_IOTLB_EVENTS, i.e. the > >iommu address space returned via get_address_space(). > > > >That being said, IOMMU_NOTIFIER_IOTLB_EVENTS should not be needed > >for passthrough devices, right? > > No, even if x-flts=on is configured in QEMU cmdline, that only mean virtual > vtd > supports stage-1 translation, guest still can choose to run in legacy > mode(stage2), > e.g., with kernel cmdline intel_iommu=on,sm_off > > So before guest run, we don't know which kind of page table either stage1 or > stage2 > for this VFIO device by guest. So we have to use iommu AS to catch stage2's > MAP event > if guest choose stage2. IIUIC, the guest kernel cmdline can switch the mode between the stage1 (nesting) and stage2 (legacy/emulated VT-d), right? Thanks Nicolin
