Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table

[Martin Lucina <martin@xxxxxxxxxx>]

On Wednesday, 10.06.2020 at 14:40, Andrew Cooper wrote:
> > So, going with the grant v2 ABI, is there a modern equivalent of
> > GNTTABOP_get_status_frames? Reading memory.h I'm guessing that it might be
> > XENMEM_add_to_physmap with space=XENMAPSPACE_grant_table and
> > idx=(XENMAPIDX_grant_table_status + N) where N is the frame I want, but
> > this is not explicitly mentioned anywhere and Linux uses the GNTTABOP
> > mechanism.
> >
> > Further to that, what is the format of the grant status frames?
> > grant_table.h doesn't have much to say about it.
> >
> > And lastly, given that I want the v2 grant ABI exclusively, I presume it's
> > sufficient to call GNTTABOP_set_version (version=2) first thing and abort
> > if it failed? Presumably the default is always v1 at start of day?
> 
> What kind of guests are you trying to target here?

PVHv2 only. x86_64 only for now, though the code should remain easily
portable to at least ARM64, should someone decide they need that.

> Since my reply, I tried to experiment, and I think you're forced to use
> GNTTABOP_setup_table/GNTTABOP_get_status_frames for x86 PV guests, and
> XENMEM_add_to_physmap for x86 HVM/PVH guests.
> 
> You can't depend on version 2 being available.  Its not available for
> ARM at all, and may be disabled for security reasons on x86 (there was
> some extended fun with transitive grants in the past, and we offered
> "totally disable grant v2" as one mitigation).

I don't need v2 at all, I was just going by the comments in grant_table.h,
which read: "Version 1 of the grant table entry structure is maintained
purely for backwards compatibility.  New guests should use version 2."

Grant status frames are a v2-only thing, right? Or can I use v1 and ask for
grant status frames?

-mato