RE: [PATCH v3 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices

[Tian, Kevin]

> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Friday, April 10, 2026 8:05 PM
> 
> On Fri, Apr 10, 2026 at 03:13:59AM +0000, Tian, Kevin wrote:
> > > From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> > > Sent: Friday, April 10, 2026 6:53 AM
> > >
> > > On Thu, Apr 09, 2026 at 03:45:26PM -0700, Nicolin Chen wrote:
> > >
> > > > One question regarding VM case: if a device is ats_always_on, while
> > > > VM somehow doesn't set nested_domain->enable_ats. Should the
> kernel
> > > > at least spit a warning, given that it would surely fail the device?
> > >
> > > No, just let break, the resulting failure has to be contained to the
> > > VM or the platform is broken..
> > >
> > > The HV can't turn on ATS because we it can't know what invalidations
> > > to push so not much other choice.
> > >
> >
> > Taking about in theory - host can append a devtlb invalidation cmd
> > after iotlb invalidation (if vcmdq is not used)?
> 
> It can't map an ASID to a BDF without shadowing all the STE and CD
> tables which we don't do for nesting.
> 

I see - on VT-d the PASID table is managed by host which requires 
explicit pasid attach then that knowledge is a side effect, but it's
certainly not the case on ARM side...