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