lkml.org 
[lkml]   [2023]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v6 0/6] iommufd: Add nesting infrastructure (part 2/2)
On Mon, Dec 11, 2023 at 08:36:46PM +0800, Yi Liu wrote:
> On 2023/12/11 10:29, Tian, Kevin wrote:
> > > From: Jason Gunthorpe <jgg@nvidia.com>
> > > Sent: Saturday, December 9, 2023 9:47 AM
> > >
> > > What is in a Nested domain:
> > > Intel: A single IO page table refereed to by a PASID entry
> > > Each vDomain-ID,PASID allocates a unique nesting domain
> > > AMD: A GCR3 table pointer
> > > Nesting domains are created for every unique GCR3 pointer.
> > > vDomain-ID can possibly refer to multiple Nesting domains :(
> > > ARM: A CD table pointer
> > > Nesting domains are created for every unique CD table top pointer.
> >
> > this AMD/ARM difference is not very clear to me.
> >
> > How could a vDomain-ID refer to multiple GCR3 pointers? Wouldn't it
> > lead to cache tag conflict when a same PASID entry in multiple GCR3 tables
> > points to different I/O page tables?
>
> Perhaps due to only one DomainID in the DTE table indexed by BDF? Actually,
> the vDomainID will not be used to tag cache, the host DomainId would be
> used instead. @Jason?

The DomainID comes from the DTE table which is indexed by the RID, and
the DTE entry points to the GCR3 table. So the VM certainly can setup
a DTE table with multiple entires having the same vDomainID but
pointing to different GCR3's. So the VMM has to do *something* with
this.

Most likely this is not a useful thing to do. However what should the
VMM do when it sees this? Block a random DTE or push the duplication
down to real HW would be my options. I'd probably try to do the latter
just on the basis of better emulation.

Jason

\
 
 \ /
  Last update: 2023-12-11 14:09    [W:0.080 / U:0.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site