Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table

[Julien Grall <julien@xxxxxxx>]

On 09/06/2020 11:50, Anil Madhavapeddy wrote:
> On 9 Jun 2020, at 11:22, Andrew Cooper <andrew.cooper3@xxxxxxxxxx 
> <mailto:andrew.cooper3@xxxxxxxxxx>> wrote:
> > On 09/06/2020 10:44, Martin Lucina wrote:
> > > Hi,
> > >
> > > I've been making progress on bootstrapping a new, PVHv2 only, Xen 
> > > platform
> > > stack for MirageOS [1]. The basics are now functional and I have 
> > > started to
> > > re-implement the grant table code.
> > >
> > > After studying both the Mini-OS and Linux implementations some, I don't
> > > understand the difference between using XENMAPSPACE_grant_table vs.
> > > GNTTABOP_setup_table to set up the initial grant table mapping for the
> > > guest.
> > >
> > > Are these calls just newer and older ways of accomplishing the same 
> > > thing?
> > > The Linux driver seems to use both in various conditions, whereas Mini-OS
> > > uses the former on ARM and the latter on x86.
> > >
> > > If these are functionally equivalent, then for my purposes I'd rather use
> > > XENMAPSPACE_setup_table, since IIUC this lets me map the grant table 
> > > at an
> > > address of my choosing rather than GNTTABOP_setup_table which at least on
> > > x86_64 appears to be returning PFNs at the top of the address space.
> > >
> > > Any advice much appreciated,
> > There is a little bit of history here...
> >
> > GNTTABOP_setup_table was the original PV way of doing things (specify
> > size as an input, get a list of frames as an output to map), and
> > XENMAPSPACE_grant_table was the original HVM way of doing things (as
> > mapping is the other way around - I specify a GFN which I'd like to turn
> > into a grant table mapping).
> >
> > When grant v2 came along, it was only XENMAPSPACE_grant_table updated to
> > be compatible.  i.e. you have to use XENMAPSPACE_grant_table to map the
> > status frames even if you used GNTTABOP_setup_table previously.
> >
> > It is a mistake that GNTTABOP_setup_table was usable in HVM guests to
> > being with.  Returning -1 is necessary to avoid an information leak (the
> > physical address of the frames making up the grant table) which an HVM
> > guest shouldn't, and has no use knowing.
> >
> > An with that note, ARM is extra special because the grant API is
> > specified to use host physical addresses rather than guest physical (at
> > least for dom0, for reasons of there generally not being an IOMMU),
> > which is why it does use the old PV way.
> Thanks, that makes sense. It doesn't seem too much of a mess from the guest
> perspective to use just XENMAPSPACE_grant_table exclusively then.  With
> Martin's work, the MirageOS Xen backend should just use the latest and 
> greatest
> APIs, with no backwards compatibility to older Xen versions required.
>
> I'm still a little confused about ARM though -- is there an equivalent of
> XENMAPSPACE_grant_table there? It sounds like we can't leave the
> GNTTABOP macros behind entirely...
XENMAPSPACE_grant_table exists and works perfectly fine on Arm. It is 
using guest physical address as it should.
Cheers,

--
Julien Grall