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.
Thanks,
Shameer
