[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] per-domain passthrough/iommu options


  • To: 'Jan Beulich' <JBeulich@xxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Fri, 26 Jul 2019 14:54:29 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=Paul.Durrant@xxxxxxxxxx; spf=Pass smtp.mailfrom=Paul.Durrant@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: "xen-devel \(xen-devel@xxxxxxxxxxxxxxxxxxxx\)" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 26 Jul 2019 14:54:36 +0000
  • Ironport-sdr: fLiTLvFvtOAsLhoTmP7VAbDaLXghH9oTgyBLRNGj0zSbP3NMd1hUABUdGYeDpZ1ciXmQRrjY8k ne4CDVP4PQcJkyb/td0Rc19o1kyKpT8whDm2ZSfex84jL2H94VOW7Y93zIV82vX9xK9p0IX622 ajtq3pxZHBXGHYs+u7vgV1DyS3E/N95XeM5CcfAAYdERtp1bM/ZqwKMS9scwnTJwOA5Oe9PYak QTo0dVfdASLserhXR2w+b47wjsx9Txi2asPNVTGavZ7Je/nwsD2dYfhktNH310I1JRrSPYX9bC hqs=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AdVDqy2gdS3slVvQRuCN/iB10JmJ2gABnjsAAAD6vMAAAUXLgAAASpcAAADXF4AAAKXGUA==
  • Thread-topic: [Xen-devel] per-domain passthrough/iommu options

> -----Original Message-----
> From: Jan Beulich <JBeulich@xxxxxxxx>
> Sent: 26 July 2019 15:34
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel (xen-devel@xxxxxxxxxxxxxxxxxxxx) 
> <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] per-domain passthrough/iommu options
> 
> On 26.07.2019 16:26, Paul Durrant wrote:
> >> From: Jan Beulich <JBeulich@xxxxxxxx>
> >> Sent: 26 July 2019 15:02
> >>
> >> On 26.07.2019 15:39, Paul Durrant wrote:
> >>> ? I don't think 'private-pt' or 'separate-pt' really capture the fact 
> >>> that the page tables match
> the
> >> P2M. They could just as easily be taken to mean that they are populated 
> >> using some other policy.
> >>
> >> But haven't we recently seen that this fully lock-step population
> >> of page tables isn't always correct (or at least desirable)? I
> >> vaguely recall other comments to that effect too, from long ago.
> >> I'd specifically want to avoid encoding into the interface here
> >> that the two are exact mirrors of one another, now and forever.
> >
> > How do you think we should express it. I agree that it's a bit awkward 
> > because of the difference
> between HVM and PV domains, but all we can do there really is document it I 
> think, so perhaps the
> manpage could have something like:
> 
> Sounds reasonable - it at least avoids making the behavior too
> much spelled out with regard to the similarity of mappings between
> IOMMU page tables and P2M. There's one issue though:
> 
> > 'off'
> >
> > IOMMU mappings are disabled for the domain and so hardware may not be 
> > passed through.
> >
> > 'sync-pt'
> >
> > For a PV domain, all writable pages assigned to the domain are identity 
> > mapped by MFN in the IOMMU
> page tables. Thus a device driver running in the domain may program 
> passthrough hardware for DMA using
> MFN values (i.e. host/machine frame numbers) looked up in its P2M.
> > For an HVM domain, all non-foreign RAM pages present in the P2M will be 
> > identity mapped by GFN
> 
> Why "identity mapped" here? It's a GFN -> MFN mappingm, isn't it?

Yes... it's hard to express. What I want to say, of course, is that device 
drivers can use GFNs. Can you think of any other form of words that might be 
better?

  Paul

> 
> Jan
> 
> > in the IOMMU page tables. Thus a device driver running in the domain may 
> > program passthrough
> hardware using GFN values (i.e. guest physical frame numbers) without any 
> further translation.
> >
> > 'share-pt'
> >
> > This is unavailable for a PV domain. For an HVM domain, this option means 
> > that the IOMMU will be
> programmed to directly reference the P2M as its page tables. This 
> availability of this option is
> hardware specific and thus, if it is specified for a domain running on 
> hardware that does not allow
> it, 'sync-pt' will be used instead.
> >
> > ?
> >
> >    Paul
> >
> >>
> >> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.