Re: grant_table_op v2 support for HVM?

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 20/04/2020 21:38, Jaromír Doleček wrote:
> Hello,
>
> I'm working on NetBSD Xen support.
>
> Recently, we've switched to grant version 2 mainly for the improved
> status handling,

Really?  The status handling is certainly different, but v2 is much
harder to use correctly.

>  and eventually for copy-only subpage grant support,
> which I'd like to experiment with in our netback driver. Currently we
> don't need the 64-bit frame, which I found was reason to Linux was
> switched over to v2 a while ago.
>
> However, later found out that HVM doesn't actually seem to support the
> GNTTABOP_get_status_frames hypercall, so had to fall back to v1 for
> HVM. Code in xen/arch/x86/hvm/hypercall.c, which doesn't have any
> handling in GNTTABOP_get_status_frames neither in Xen 4.11/4.12/4.13.
>
> Can you advise which version should be used by Dom0/DomU kernels?
>
> Is there some way to still use v2 with HVM? Possibly instead of using
> the status frames, still use the old cmpxchg16 method on hdr.flags,
> but as I understand hdr.flags is not used for GTF_reading and
> GTF_writing in v2. I also see the set_version and get_version calls
> are still supported even for HVM.
>
> Understandably, we'd prefer to use same version for PV and HVM kernels.

Like many things, PV and HVM are different.

For PV, the guest creates the mapping.  You've got to ask Xen for the
list of MFNs, so you can create a PTE pointing at them.

For HVM, you've got to decide were you'd like the frames in your guest
physical space, and ask Xen to make the adjustment.

You want add_to_physmap(), requesting XENMAPSPACE_grant_table and or-ing
XENMAPIDX_grant_table_status into the index.  (Because a new
XENMAPSPACE_grant_status apparently wasn't the most logical way to
extend the existing interface.)

i.e. duplicate the existing grant frame logic, picking a second set of
gfns, and tweaking the index input.

~Andrew