> -----Original Message----- > From: Markus Armbruster <[email protected]> > Sent: 12 March 2026 08:21 > To: Shameer Kolothum Thodi <[email protected]> > Cc: Nathan Chen <[email protected]>; [email protected]; qemu- > [email protected]; 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]>; Cédric Le > Goater <[email protected]>; Eric Blake <[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 > > > Shameer Kolothum Thodi <[email protected]> writes: > > >> -----Original Message----- > >> From: Markus Armbruster <[email protected]> > > [...] > > >> Nathan Chen <[email protected]> writes: > >> > >> > 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. > >> > > >> > Subsequent patches will make use of this helper to set the values > >> > when we convert the values to OnOffAuto. New auto_mode and > >> > auto_finalised bool members are added to SMMUv3AccelState. > >> > smmuv3_accel_init() will set auto_mode to true when 'auto' is > >> > detected for the accel SMMUv3 properties. > >> > smmuv3_accel_auto_finalise() will set auto_finalised to true after > >> > all 'auto' properties are resolved, and subsequent calls to this > >> > function will return early if auto_finalised is set to true. > >> > > >> > Suggested-by: Shameer Kolothum <[email protected]> > >> > Signed-off-by: Nathan Chen <[email protected]> > >> > --- > >> > hw/arm/smmuv3-accel.c | 38 > +++++++++++++++++++++++++++++++++-- > >> --- > >> > hw/arm/smmuv3-accel.h | 2 ++ > >> > 2 files changed, 35 insertions(+), 5 deletions(-) > >> > > >> > diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c index > >> > 17306cd04b..617629bacd 100644 > >> > --- a/hw/arm/smmuv3-accel.c > >> > +++ b/hw/arm/smmuv3-accel.c > >> > @@ -35,11 +35,34 @@ static int smmuv3_oas_bits(uint32_t oas) > >> > return map[oas]; > >> > } > >> > > >> > +static void smmuv3_accel_auto_finalise(SMMUv3State *s, PCIDevice > *pdev, > >> > + struct iommu_hw_info_arm_smmuv3 > >> > *info) { > >> > + SMMUv3AccelState *accel = s->s_accel; > >> > + > >> > + /* Return if no auto for any or finalised already */ > >> > + if (!accel->auto_mode || accel->auto_finalised) { > >> > + return; > >> > + } > >> > + > >> > + /* We can't update if device is hotplugged */ > >> > + if (DEVICE(pdev)->hotplugged) { > >> > + warn_report("arm-smmuv3: 'auto' feature property detected, > >> > + but host > >> " > >> > + "value cannot be applied for hot-plugged device; > >> > using " > >> > + "existing value"); > >> > >> Why is this warning useful? > >> > >> Does @auto's meaning depend on whether the device is cold- or > >> hot-plugged? > > > > If SMMUv3 accel=on and properties are set to "auto", we require at > > least one cold-plugged vfio-pci device to retrieve the associated host > > SMMUv3 information and finalise the QEMU SMMUv3 properties. > > > > In this series, "auto_mode" is set if any accel property is specified > > as "auto". The properties are then finalised using the first > > cold-plugged device and "auto_finalised" is set. > > > > Since we later fail the guest boot(see below) in the reset phase if > > auto_mode is set but auto_finalised is still false, the above hotplug > > case should not really happen. In that case the VM would not boot. > > Sounds complicated. > > > So likely we can get rid of the hotplug check above. Need to do a bit > > more testing to confirm we cover all corner cases. > > > >> > >> > + return; > >> > + } > >> > + > >> > + accel->auto_finalised = true; > >> > +} > > [...] > > >> > @@ -867,8 +891,12 @@ bool > smmuv3_accel_attach_gbpa_hwpt(SMMUv3State > >> > *s, Error **errp) > >> > > >> > void smmuv3_accel_reset(SMMUv3State *s) { > >> > - /* Attach a HWPT based on GBPA reset value */ > >> > - smmuv3_accel_attach_gbpa_hwpt(s, NULL); > >> > + if (s->s_accel && s->s_accel->auto_mode && > >> > + !s->s_accel->auto_finalised) > >> { > >> > + error_report("AUTO mode specified but properties not > >> > finalised."); > >> > + exit(1); > >> > >> How can we get here? > > > > This is reached from the SMMUv3 reset handler when auto mode is > > specified but no cold-plugged device has been attached to finalise the > > accelerated SMMUv3 properties. > > > > If no such device is present, "auto_finalised" remains false and we hit > > this path during reset. > > > > Cédric mentioned that we should not exit during the reset phase. If that > > is the case, we likely need another way to handle the scenario where > > auto mode is specified but no cold-plugged device is present. > > What exactly does the "auto" feature buy us? Is it worth the > complexity?
The requirement came from the KubeVirt folks. It is easier for them if QEMU can probe the platform and set these values, instead of specifying them for each platform. See: https://lore.kernel.org/qemu-devel/[email protected]/ Without "auto", the management layer needs to know the values supported on each platform. eg: on a GB200, it will look like, -device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.0,accel=on,ats=on,ril=off,ssidsize=20,oas=48 With "auto" it can simply be: -device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.0,accel=on (provided a vfio-pci device is cold-plugged). Thanks, Shameer
