Hi Shameer, On 9/8/25 9:41 AM, Shameer Kolothum wrote: > Hi Eric, > >> -----Original Message----- >> From: Eric Auger <[email protected]> >> Sent: 05 September 2025 09:15 >> To: Duan, Zhenzhong <[email protected]>; Nicolin Chen >> <[email protected]>; Shameer Kolothum <[email protected]> >> Cc: [email protected]; [email protected]; >> [email protected]; Jason Gunthorpe <[email protected]>; >> [email protected]; [email protected]; Nathan Chen >> <[email protected]>; Matt Ochs <[email protected]>; >> [email protected]; [email protected]; [email protected]; >> [email protected]; [email protected]; >> [email protected]; [email protected] >> Subject: Re: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated >> SMMUv3 to vfio-pci endpoints with iommufd >> > [..] >>>>>> static AddressSpace *smmuv3_accel_find_add_as(PCIBus *bus, void >>>>>> *opaque, >>>>>> int devfn) >>>>>> { >>>>>> + PCIDevice *pdev = pci_find_device(bus, pci_bus_num(bus), devfn); >>>>>> SMMUState *bs = opaque; >>>>>> + bool vfio_pci = false; >>>>>> SMMUPciBus *sbus; >>>>>> SMMUv3AccelDevice *accel_dev; >>>>>> SMMUDevice *sdev; >>>>>> >>>>>> + if (pdev && !smmuv3_accel_pdev_allowed(pdev, &vfio_pci)) { >>>>>> + error_report("Device(%s) not allowed. Only PCIe root complex >>>>>> devices " >>>>>> + "or PCI bridge devices or vfio-pci endpoint >>>> devices >>>>>> with " >>>>>> + "iommufd as backend is allowed with >>>>>> arm-smmuv3,accel=on", >>>>>> + pdev->name); >>>>>> + exit(1); >>>>> Seems aggressive for a hotplug, could we fail hotplug instead of kill >> QEMU? >>>> Hotplug will unlikely be supported well, as it would introduce >>>> too much complication. >>>> >>>> With iommufd, a vIOMMU object is allocated per device (vfio). If >>>> the device fd (cdev) is not yet given to the QEMU. It isn't able >>>> to allocate a vIOMMU object when creating a VM. >>>> >>>> While a vIOMMU object can be allocated at a later stage once the >>>> device is hotplugged. But things like IORT mappings aren't able >>>> to get refreshed since the OS is likely already booted. Even an >>>> IOMMU capability sync via the hw_info ioctl will be difficult to >>>> do at the runtime post the guest iommu driver's initialization. >>>> >>>> I am not 100% sure. But I think Intel model could have a similar >>>> problem if the guest boots with zero cold-plugged device and then >>>> hot-plugs a PASID-capable device at the runtime, when the guest- >>>> level IOMMU driver is already inited? >>> For vtd we define a property for each capability we care about. >>> When hotplug a device, we get hw_info through ioctl and compare >>> host's capability with virtual vtd's property setting, if incompatible, >>> we fail the hotplug. >>> >>> In old implementation we sync host iommu caps into virtual vtd's cap, >>> but that's Naked by maintainer. The suggested way is to define property >>> for each capability we care and do compatibility check. >>> >>> There is a "pasid" property in virtual vtd, only when it's true, the PASID- >> capable >>> device can work with pasid. >>> >>> Zhenzhong >> I don't think this is an option not to support hotplug. I agree with >> Zhenzhong, we shall try to align with the way it is done on intel-iommu >> and study whether it also fits the needs for accelerated smmu. > Hotplug is supported. The only current requirement is that we need at least > one cold-plugged device to retrieve the host SMMUv3 features. These are > then used to update the vSMMUv3 features during the reset phase so that > the Guest can probe them at boot. > > Based on the discussions in this series, we plan to remove that dependency > going forward. Instead, the accelerated vSMMUv3 will be initialized based > on the current emulated SMMUv3 features, plus any additional features > specified by the user on the command line. > > During every device attachment to the accelerated SMMUv3, we will > cross-check for any disparities and allow or disallow the attachment > accordingly. > > Please let me know if you see any drawbacks with this approach. This looks aligned with the intel-iommu strategy and up to now I don't see any cons. Let's try to relax the requirement and we will see if it brings further issues ...
Thanks Eric > > Thanks, > Shameer > > > >
