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 How do you distinguish an old kernel which is not capable of returning the cap info from a new kernel that effectively returns the capability is not supported. > -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
I am not sure how it works with an old kernel. auto or on would keep ATS=off while it is currently set today, no? Thanks Eric > (this also covers behaviour on older kernels) > > Does the above make sense? > > Thanks, > Shameer >
