On Thu, Jul 10, 2025 at 01:07:11PM -0400, Donald Dutile wrote:
> > > > If not, maybe go a bit further like "VIOMMU_CAP_HW_NESTED_S1"?
> > >
> > > I am not sure the _S1 part makes much sense in ARM case. It doesn't matter
> > > whether the Guest SMMUv3 is configured in s1/s2 or nested for this CAP.
> > > With the new SMMUv3 dev support, the user can pretty much specify,
> > >
> > > -device
> > > arm-smmuv3,primary-bus=pcie.0,id=smmuv3.1,accel=on,stage={stage1|stage2|nested}
> > >
> > > And I think it will work with a host SMMUv3 nested configuration in all
> > > the
> > > above cases. Unless I am missing something and we need to restrict its
> > > use with stage=stage1 only.
> > >
> > > Thanks,
> > > Shameer
> > >
> Shameer,
> I didn't think of these config options this way... so is this CAP always 0
> for smmuv3's associated VIOMMU?
There should be a "bool hw_nesting" flag (or some other name) in
the SMMUState or SMMUDevice structure, that's set earlier by the
support of nested HWPT allocation/invalidation and other factors.
E.g. if "accel=on" is missing, set hw_nesting to false.
Then SMMU's get_viommu_cap() callback function will simply check
that flag.
> or ... should intel-iommu follow this same/smmuv3 config option(s) and avoid
> this VIOMMU CAP req. ?
We need this CAP for the vfio/pci core to allocate an S2 nesting
parent HWPT.
Thanks
Nicolin
