Re: One question about the hypercall to translate gfn to mfn.

[Ian Campbell <Ian.Campbell@citrix.com>]

On Tue, 2014-12-09 at 11:17 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 09 December 2014 11:11
> > To: Paul Durrant
> > Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); JBeulich@suse.com;
> > Xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] One question about the hypercall to translate gfn to
> > mfn.
> > 
> > On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Tim Deegan [mailto:tim@xen.org]
> > > > Sent: 09 December 2014 10:47
> > > > To: Yu, Zhang
> > > > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> > > > devel@lists.xen.org
> > > > Subject: Re: One question about the hypercall to translate gfn to mfn.
> > > >
> > > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > > > Hi all,
> > > > >
> > > > >    As you can see, we are pushing our XenGT patches to the upstream.
> > One
> > > > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > > > > device model.
> > > > >
> > > > >    Here we may have 2 similar solutions:
> > > > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there
> > was
> > > > no
> > > > > usage at that time.
> > > >
> > > > It's been suggested before that we should revive this hypercall, and I
> > > > don't think it's a good idea.  Whenever a domain needs to know the
> > > > actual MFN of another domain's memory it's usually because the
> > > > security model is problematic.  In particular, finding the MFN is
> > > > usually followed by a brute-force mapping from a dom0 process, or by
> > > > passing the MFN to a device for unprotected DMA.
> > > >
> > > > These days DMA access should be protected by IOMMUs, or else
> > > > the device drivers (and associated tools) are effectively inside the
> > > > hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> > > > presumably present on anything new enough to run XenGT?).
> > > >
> > > > So I think the interface we need here is a please-map-this-gfn one,
> > > > like the existing grant-table ops (which already do what you need by
> > > > returning an address suitable for DMA).  If adding a grant entry for
> > > > every frame of the framebuffer within the guest is too much, maybe we
> > > > can make a new interface for the guest to grant access to larger areas.
> > > >
> > >
> > > IIUC the in-guest driver is Xen-unaware so any grant entry would have
> > > to be put in the guests table by the tools, which would entail some
> > > form of flexibly sized reserved range of grant entries otherwise any
> > > PV driver that are present in the guest would merrily clobber the new
> > > grant entries.
> > > A domain can already priv map a gfn into the MMU, so I think we just
> > >  need an equivalent for the IOMMU.
> > 
> > I'm not sure I'm fully understanding what's going on here, but is a
> > variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign which
> > also
> > returns a DMA handle a plausible solution?
> > 
> 
> I think we want be able to avoid setting up a PTE in the MMU since
> it's not needed in most (or perhaps all?) cases.

Another (wildly under-informed) thought then:

A while back Global logic proposed (for ARM) an infrastructure for
allowing dom0 drivers to maintain a set of iommu like pagetables under
hypervisor supervision (they called these "remoteprocessor iommu").

I didn't fully grok what it was at the time, let alone remember the
details properly now, but AIUI it was essentially a framework for
allowing a simple Xen side driver to provide PV-MMU-like update
operations for a set of PTs which were not the main-processor's PTs,
with validation etc.

See http://thread.gmane.org/gmane.comp.emulators.xen.devel/212945

The introductory email even mentions GPUs...

Ian.