> -----Original Message----- > From: Cédric Le Goater <[email protected]> > Sent: 12 March 2026 08:37 > To: Shameer Kolothum Thodi <[email protected]>; Nathan Chen > <[email protected]>; [email protected]; [email protected] > Cc: Yi Liu <[email protected]>; Eric Auger <[email protected]>; > Zhenzhong Duan <[email protected]>; Peter Maydell > <[email protected]>; Shannon Zhao <[email protected]>; > Michael S . Tsirkin <[email protected]>; Igor Mammedov > <[email protected]>; Ani Sinha <[email protected]>; Paolo > Bonzini <[email protected]>; Daniel P . Berrangé > <[email protected]>; Alex Williamson <[email protected]>; Eric Blake > <[email protected]>; Markus Armbruster <[email protected]> > Subject: Re: [RFC PATCH 1/8] hw/arm/smmuv3-accel: Add helper for resolving > auto parameters > > External email: Use caution opening links or attachments > > > Hello Shameer > > On 3/10/26 09:40, Shameer Kolothum Thodi wrote: > > > > > >> -----Original Message----- > >> From: Cédric Le Goater <[email protected]> > >> Sent: 10 March 2026 07:42 > >> To: Nathan Chen <[email protected]>; [email protected]; > qemu- > >> [email protected] > >> Cc: Yi Liu <[email protected]>; Eric Auger <[email protected]>; > >> Zhenzhong Duan <[email protected]>; Peter Maydell > >> <[email protected]>; Shannon Zhao > <[email protected]>; > >> Michael S . Tsirkin <[email protected]>; Igor Mammedov > >> <[email protected]>; Ani Sinha <[email protected]>; Paolo > >> Bonzini <[email protected]>; Daniel P . Berrangé > >> <[email protected]>; Alex Williamson <[email protected]>; Eric Blake > >> <[email protected]>; Markus Armbruster <[email protected]>; > >> Shameer Kolothum Thodi <[email protected]> > >> Subject: Re: [RFC PATCH 1/8] hw/arm/smmuv3-accel: Add helper for > resolving > >> auto parameters > >> > >> External email: Use caution opening links or attachments > >> > >> > >> On 3/9/26 20:21, Nathan Chen wrote: > >>> From: Nathan Chen <[email protected]> > >>> > >>> Introduce smmuv3_accel_auto_finalise() to resolve properties > >>> that are set to 'auto' for accelerated SMMUv3. This helper > >>> function allows properties such as ATS, RIL, SSIDSIZE, and OAS > >>> support to be resolved from host IOMMU values, while avoiding > >>> triggering auto-resolved values for hot-plugged devices. > >>> > >>> Auto mode requires at least one cold-plugged device to retrieve > >>> and finalise these properties, and we fail boot if that is not > >>> the case. > >> > >> IIUC, QEMU will require a minimum of one PCI device if > >> arm-smmuv3,accel=on is passed on the command line and if the > >> smmu properties are set to 'auto'. > > > > Yes, that’s correct. > > > >> I would try to enforce this requirement in the realize routine. > >> Can't we leverage the supports_address_space() handler ? See : > >> > >> > >> static bool smmuv3_accel_supports_as(PCIBus *bus, void *opaque, int > >> devfn, > >> Error **errp) > >> { > >> PCIDevice *pdev = pci_find_device(bus, pci_bus_num(bus), devfn); > >> bool vfio_pci = false; > >> > >> if (pdev && !smmuv3_accel_pdev_allowed(pdev, &vfio_pci)) { > >> if (vfio_pci) { > >> error_setg(errp, "vfio-pci endpoint devices without an > >> iommufd > " > >> "backend not allowed when using arm- > smmuv3,accel=on"); > >> ... > > Hmm..i doubt we can do it here as we need HostIOMMUDeviceIOMMUFD > *idev > > for retrieving the IOMMU_GET_HW_INFO. > > > > supports_address_space() is invoked very early during > do_pci_register_device() > > and there are no associated idev available at that time. > > > yes. Have your considered adding an 'iommufd' property to smmuv3 > instead ? I think this should solve a lot of potential issues > and would be more model friendly. > > Sorry if that was proposed already. I have been through all the > emails.
As I replied in the other thread, we need an idev for retrieving hw info. [...] > >> > >>> + exit(1); > >> > >> QEMU should not exit in the reset phase. Can this check be done during > >> the realize stage ? > > > > SMMUv3 realize stage happens before the cold-plugged device > > set_iommu_device(), and therefore we can't check whether the SMMUv3 > > properties have been retrieved and finalised at that point. > > > > Not sure there is any other place we can do this other than in the reset > > path. > > > > Is avoiding exit(1) in the reset phase a strict requirement or a nice to > > have one? > > reset is a runtime handler called at each reboot. One should not > exit. > > We should try to verify that the conditions to run the machine > are correct before reaching the reset phase. > Ok. In that case, could we register a qemu_add_machine_init_done_notifier() for SMMUv3 and move this verification there? Thanks, Shameer
