[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB5276DDE04A315B1F870872468C062@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Wed, 10 Apr 2024 23:23:57 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>
CC: Baolu Lu <baolu.lu@...ux.intel.com>, "iommu@...ts.linux.dev"
<iommu@...ts.linux.dev>, "Liu, Yi L" <yi.l.liu@...el.com>, Joerg Roedel
<joro@...tes.org>, Will Deacon <will@...nel.org>, Robin Murphy
<robin.murphy@....com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/2] iommu/vt-d: Remove caching mode check before devtlb
flush
> From: Jacob Pan <jacob.jun.pan@...ux.intel.com>
> Sent: Thursday, April 11, 2024 12:20 AM
>
> Hi Kevin,
>
> On Wed, 10 Apr 2024 00:32:06 +0000, "Tian, Kevin" <kevin.tian@...el.com>
> wrote:
>
> > > From: Jacob Pan <jacob.jun.pan@...ux.intel.com>
> > > Sent: Wednesday, April 10, 2024 1:32 AM
> > >
> > > If the guest uses SL page tables in vIOMMU, we don;t expose ATS to the
> > > guest. So ATS is not relevant here, does't matter map or unmap.
> > >
> >
> > ATS is orthogonal to SL vs. FL. Where is this restriction coming from?
> For practical purposes, what would be the usage to have SL in the guest and
> ATS enabled. i.e. shadowing SL but directly expose ATS?
>
ATS is about the protocol between device and iommu to look up
translations. Why does it care about internal paging layout in
iommu?
I'm not sure which spec explicitly states such restriction.
Powered by blists - more mailing lists