> -----Original Message-----
> From: Jason Gunthorpe <[email protected]>
> Sent: 02 February 2026 15:19
> 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:11:28PM +0000, Shameer Kolothum Thodi
> wrote:
> > > RIL is in IDR3
> > > ssidsize in IDR1
> > > OAS in IDR5
> > > ATS may be more touchy but maybe this can be introspected too?
> >
> > Yeah. ATS might require some kernel plumbing as BIOS can override it.
> 
> 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?

Thanks,
Shameer


Reply via email to