Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [PATCH 1/1] iommu/vt-d: Add opt-in for ATS support on discrete devices | Date | Tue, 7 Mar 2023 05:20:07 +0000 |
| |
> From: Jason Gunthorpe <jgg@nvidia.com> > 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@nvidia.com> > > > 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.
| |