On Fri, Nov 21, 2025 at 02:22:21AM -0800, Shameer Kolothum wrote:
> > > @@ -2084,6 +2090,7 @@ static const Property smmuv3_properties[] = {
> > > DEFINE_PROP_BOOL("ril", SMMUv3State, ril, true),
> > > DEFINE_PROP_BOOL("ats", SMMUv3State, ats, false),
> > > DEFINE_PROP_UINT8("oas", SMMUv3State, oas, 44),
> > > + DEFINE_PROP_BOOL("pasid", SMMUv3State, pasid, false),
> > > };
> >
> > Instead of doing a boolean "pasid", perhaps ssidsize and sidsize
> > should be configurable. Then, user can follow the not-compatible
> > print to set correct SSIDSIZE and SIDSIZE.
>
> Do we really need that? Currently both are set to 16 which means 64K
> values are supported. I think we can make it configurable when any
> usecase with >64K requirement comes up.
For upper boundary, we have SoCs with SSIDSIZE=0x14 i.e. 20. I
am not sure how user space would use this range, but I feel it
is better not to cap it. And SIDSIZE=16 is probably way enough
given that QEMU only has one PCI Bus domain.
For lower boundary, SMMUv3 spec defines:
SSIDSIZE, bits [10:6]
Max bits of SubstreamID.
Valid range 0 to 20 inclusive, 0 meaning no substreams are supported.
and
SIDSIZE, bits [5:0]
Max bits of StreamID.
This value is between 0 and 32 inclusive.
Note: 0 is a legal value. In this case the SMMU supports one stream.
We apply a hard requirement that a host value must >= VM value.
This might not work for hardware that has smaller numbers.
Yes, we may add an SIDSIZE when somebody actually wants it. But
the "bool pasid" would be very useless when we add an SSIDSIZE.
So, I think it's nicer to define "uint32 ssidsize" in the first
place, which also aligns the QEMU parameter with the HW naming.
Nicolin
