Hi Eric, > -----Original Message----- > From: Eric Auger <[email protected]> > Sent: 02 February 2026 14:40 > To: Shameer Kolothum Thodi <[email protected]>; qemu- > [email protected]; [email protected] > Cc: [email protected]; Jason Gunthorpe <[email protected]>; Nicolin > Chen <[email protected]>; [email protected]; [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]; Krishnakant Jaju > <[email protected]> > Subject: Re: [PATCH v9 31/37] hw/arm/smmuv3-accel: Add property to > specify OAS bits > > External email: Use caution opening links or attachments > > > Hi Shameer, Nicolin, > On 1/26/26 11:43 AM, Shameer Kolothum wrote: > > QEMU SMMUv3 currently sets the output address size (OAS) to 44 bits. > > With accelerator mode enabled, a device may use SVA, where CPU page > tables > > are shared with the SMMU, requiring an OAS at least as large as the > > CPU’s output address size. A user option is added to configure this. > > > > However, the OAS value advertised by the virtual SMMU must remain > > compatible with the capabilities of the host SMMUv3. In accelerated > > mode, the host SMMU performs stage-2 translation and must be able to > > consume the intermediate physical addresses (IPA) produced by stage-1. > > > > The OAS exposed by the virtual SMMU defines the maximum IPA width that > > stage-1 translations may generate. For AArch64 implementations, the > > maximum usable IPA size on the host SMMU is determined by its own OAS. > > Check that the configured OAS does not exceed what the host SMMU > > can safely support. > > After discussion with Kubevirt guys, the management of current RIL, > ssidsize, ats and oas options look touchy because it is tricky for them > to introspect the host values.
I may be wrong, but it looks like Kubevirt actually makes use of libvirt. Or is it independent? The reason I am asking is Nathan is already working on the libvirt changes for this here: https://lists.libvirt.org/archives/list/[email protected]/thread/5GG76AQTTDUHW5KRANPY3QUII4ZOEYRP/ And the _AUTO suggestion might impact that as well. > In cold plug case at least it looks feasible to use IOMMU_GET_HW_INFO() > to retrieve host info: > > RIL is in IDR3 > ssidsize in IDR1 > OAS in IDR5 > ATS may be more touchy but maybe this can be introspected too? Yeah. ATS might require some kernel plumbing as BIOS can override it. > I would advocate to turn those options into _AUTO options to give a > chance to the user to ask for host derived values. > > Currently in include/hw/qdev-properties.h we have > DEFINE_PROP_ON_OFF_AUTO for a bool and > DEFINE_PROP_ON_OFF_AUTO_BIT64 for a 64b > > RIL can match bool. > Others may need a new DEFINE_PROP_ON_OFF_AUTO_* one. > > Note such kind of auto property was introduced for virtio-iommu > (DEFINE_PROP_GRANULE_MODE) > > What do you think? Most probably this has been dicussed in the past but > I do not necessarily remember the outputs. IIRC, the only conclusion was that the user has to specify the SMMUv3 parameters. Don't think the _AUTO option was discussed previously. If this is a very useful thing to have, I can take a look. Thanks, Shameer
