Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/06/2020 14:56, Martin Lucina wrote:
> 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."

Ha...

That comment wasn't written with the benefit of hindsight.

IMO, grant v2 is not worth the astounding quantity of XSAs its
implementation actually gave us, or the complexity of the resulting code.

> Grant status frames are a v2-only thing, right?

Correct.

The split status frames was new in v2, in an attempt to reduce cacheline
ping-pong.

The downside is that the guest needs an unbounded loop trying to make a
change to the grant table while ensuring that the flags in the status
frame don't change asynchronously.

~Andrew

P.S. In some theoretical world, I was hoping to have something to live
in https://xenbits.xen.org/docs/latest/guest-guide/index.html on this
subject.  Do you mind if I use you as a retroactive guineapig if/when
some documentation were to appear?