Hi Shameer, On 2/10/26 4:12 PM, Shameer Kolothum Thodi wrote: > Hi Eric, > >> -----Original Message----- >> From: Shameer Kolothum Thodi >> Sent: 02 February 2026 16:04 >> To: Jason Gunthorpe <[email protected]> >> Cc: [email protected]; [email protected]; qemu- >> [email protected]; [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 >> >> >> >>> -----Original Message----- >>> From: Jason Gunthorpe <[email protected]> >>> Sent: 02 February 2026 16:00 >>> To: Shameer Kolothum Thodi <[email protected]> >>> Cc: [email protected]; [email protected]; qemu- >>> [email protected]; [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 >>> >>> On Mon, Feb 02, 2026 at 03:38:50PM +0000, Shameer Kolothum Thodi >>> wrote: >>> >>>>> We can treat ATS as a per-PCIe device property.. I think it would >>>>> be fine to tell the SMMU that it always has ATS support, it will >>>>> never do anything with it unless it sees a PCIe device with an ATS >>>>> cap, and the physical STE generated by the hypervisor should sanitize the >> EATS. >>>>> BIOS overriding it should be reflected as the devices being >>>>> reported as not supporting ATS, qemu should have a per-device flag >>>>> to disable ATS. >>>> Do we have way to detect that(IOMMU_FWSPEC_PCI_RC_ATS) from >>>> userspace now? >>> I don't think so.. I was describing how I suspect that should work. >>> >>> The iommu driver is the only entity that decides if ATS should be >>> enabled per-device, so it should report back to userspace in iommufd >>> if the device is allowed to enable ATS or not. That should roll up any >>> FW overrides and the PCI cap block. >> Right. May be just like the out_max_pasid_log2. Will take a look. > Looking at adding the ATS detection support through iommufd, one > idea is to extend the enum iommufd_hw_capabilities with > IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED. The question I have > now is whether we need to differentiate an old kernel which doesn't > have this support or not. > > This is how the usage would look with an added "ats" property on the > vfio-pci device: > > -device vfio-pci,...,ats=on > if ATS_NOT_SUPPORTED then reject > -device vfio-pci,...,ats=off > keep ATS off > -device vfio-pci,...,ats=auto (default) > if ATS_NOT_SUPPORTED, disable ATS > otherwise, enable ATS if the PCIe ATS capability is present > (this also covers behaviour on older kernels) > > Does the above make sense? Do you have plans wrt the migration to auto properties for the various vSMMU properties (RIL, ssidsize, OAS, ATS)? I just would like to make sure libvirt integrators take this new design into account. Please let me know if some help is needed for the conversion of some of the properties?
Thanks Eric > > Thanks, > Shameer >
