On Fri, Nov 21, 2025 at 09:50:50AM -0800, Nicolin Chen wrote:
> 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.
Yeah, it should be ssize not pasid.
The use case of these values is exactly defining a SMMU instance type
so that it can migration between different physical HW. So long as
physical can implement the instance type.
Thus you broadly want to make the iidrs configurable in the exact
spec language of the iidrs, IMHO.
Jason
