Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 9 Jun 2020, at 11:22, Andrew Cooper <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...

regards,

Anil