Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/06/2020 14:22, Martin Lucina wrote:
> On Tuesday, 09.06.2020 at 11:22, Andrew Cooper wrote:
>> 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.
>>
>> It is all a bit of a mess.
> Thanks for explaining, this is helpful.
>
> 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?

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).

Use v1 unless you have a specific need to use v2 (transitive grants or
subpage copies, or support for >16TB VMs (HVM) or hosts (PV)).  Amongst
other things, its far more simple to use correctly.  (v2 devolves to
infinite loops to use correctly, because there is no way to do an atomic
option covering both the flags and status entries at the same time.)

If you need to use v2, you must cleanly cope with it not being
available, and fall back to v1.

~Andrew