> -----Original Message-----
> From: Nicolin Chen <[email protected]>
> Sent: 21 November 2025 17:51
> To: Shameer Kolothum <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; Jason Gunthorpe
> <[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 v6 33/33] hw/arm/smmuv3-accel: Add support for PASID
> enable
>
> 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,
Right. My assumption was that nobody uses that higher range per SID
now in real applications even if hardware supports that.
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.
I guess 16 is a reasonable low value for all hardware's out there now,
at least, I am not aware of anyone implementing less than that.
> Yes, we may add an SIDSIZE when somebody actually wants it. But
> the "bool pasid" would be very useless when we add an SSIDSIZE.
That make sense.
> So, I think it's nicer to define "uint32 ssidsize" in the first
> place, which also aligns the QEMU parameter with the HW naming.
Ok. Jason also made this argument that it is better to align it with IDR
names here. So I will change this to "ssidsize" so that we have all the
configurable properties align with ID register field names.
Thanks,
Shameer
