> -----Original Message----- > From: Eric Auger <[email protected]> > Sent: 10 February 2026 16:01 > To: Shameer Kolothum Thodi <[email protected]>; Jason Gunthorpe > <[email protected]> > Cc: [email protected]; [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 > > External email: Use caution opening links or attachments > > > Hi Shameer, > On 2/10/26 4:12 PM, Shameer Kolothum Thodi wrote:
> > 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. For old kernel, ATS_NOT_SUPPORTED will not be set. So we keep ATS if CAP is present in this case. But reject , if new kernels report ATS_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? Same as above, for old kernel ATS_NOT_SUPPORTED is not set. So just rely on PCIe CAP presence just like it does today. Thanks, Shameer
