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?
Thanks,
Shameer
