On 2/2/26 4:11 PM, Shameer Kolothum Thodi wrote:
> 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?
yes they do? The problem is they don't know how to set the values for
those props besides definiting a kind of hardcoded profile. They are
unused to do that. The best would be to let qemu guess the right values
by introspection through the kernel uapi.
>
> 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.
sure. That's why I discuss it tight now.
>
>> 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.
agreed
>
>> 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.
If this sounds feasible, I think this would be a more relevant approach.
The default values could be kept as is for now and we would let kubevirt
set AUTO value until the default gets changed.
Eric
>
> Thanks,
> Shameer
