Re: [future abi] [RFC PATCH V3] xen/gnttab: Store frame GFN in struct page_info on Arm

[Oleksandr <olekstysh@xxxxxxxxx>]

On 23.09.21 23:59, Andrew Cooper wrote:

Hi Andrew.

> On 23/09/2021 20:32, Oleksandr Tyshchenko wrote:
> > Suggested-by: Julien Grall <jgrall@xxxxxxxxxx>
> > Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
> > ---
> > You can find the related discussions at:
> > https://lore.kernel.org/xen-devel/93d0df14-2c8a-c2e3-8c51-54412190171c@xxxxxxx/
> > https://lore.kernel.org/xen-devel/1628890077-12545-1-git-send-email-olekstysh@xxxxxxxxx/
> > https://lore.kernel.org/xen-devel/1631652245-30746-1-git-send-email-olekstysh@xxxxxxxxx/
> >
> > ! Please note, there is still unresolved locking question here for which
> > I failed to find a suitable solution. So, it is still an RFC !
> Just FYI, I thought I'd share some of the plans for ABI v2.  Obviously
> these plans are future work and don't solve the current problem.
>
> Guests mapping Xen pages is backwards.  There are reasons why it was
> used for x86 PV guests, but the entire interface should have been design
> differently for x86 HVM.
>
> In particular, Xen should be mapping guest RAM, rather than the guest
> manipulating the 2nd stage tables to map Xen RAM.  Amongst other things,
> its far far lower overhead.
>
>
> A much better design is one where the grant table looks like an MMIO
> device.  The domain builder decides the ABI (v1 vs v2 - none of this
> dynamic switch at runtime nonsense), and picks a block of guest physical
> addresses, which are registered with Xen.  This forms the grant table,
> status table (v2 only), and holes to map into.  Details can be conveyed
> via ACPI table or DT, as applicable
>
> Xen maps the RAM (which is now accounted to the guest, an improvement
> over today) forming the grant and status tables, and grant map/unmap
> hypercalls simplify massively to just {src domid, gref, flags} => slot,
> which also solves the "is the same grant mapped elsewhere?" problem.
>
> There is never a need for HVM guests to map the same grant twice (as it
> controls the first stage tables and can create whatever alias it
> desires), but there's also no need to allow the guest to pick where the
> mapping occurs.  This vastly simplifies both the Xen and guest kernel
> implementations.
That's interesting. Thank you for detailed explanation. I think, I got 
the high level idea.

> ~Andrew
--
Regards,

Oleksandr Tyshchenko