RE: [PATCH 1/1] iommu/vt-d: Add opt-in for ATS support on discrete devices

[Tian, Kevin]

> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Friday, March 3, 2023 9:18 PM
> 
> On Fri, Mar 03, 2023 at 08:19:29AM +0000, Tian, Kevin wrote:
> > > From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> > > Sent: Thursday, March 2, 2023 1:43 AM
> > >
> > > If Intel BIOS's have populated the "satcu" to say that ATS is not
> > > supported by the HW when the HW supports ATS perfectly fine, then get
> > > the BIOS fixed or patch the ACPI until it is fixed. The BIOS should
> > > not be saying that the HW does not support ATS when it does, it is a
> > > simple BIOS bug.
> > >
> >
> > That is not the purpose of SATC.
> >
> > The ATS support in VT-d side is reported in two interfaces:
> >
> > 1) "Device-TLB support" in Extended Capability Register;
> > 2) Root port ATS capability in ACPI ATSR structure;
> >
> > A device gets ATS enabled if 1/2 are true and !pdev->untrusted. Same
> > as SMMU does.
> >
> > The main purpose of SATC is to describe which ATS-capable integrated
> > device meets the requirements of securely using ATS as stated in VT-d
> > spec 4.4.
> 
> Then it should be mapped to pdev->untrusted and possibly
> pdev->untrusted to be enhanced to be more descriptive.
> 
> iommu driver and BIOS should have no role in security policy beyond
> feeding in data to a common policy engine.
> 

That makes sense.