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

[Julien Grall <julien@xxxxxxx>]

Hi Roger,

On 24/09/2021 13:41, Roger Pau Monné wrote:
> On Thu, Sep 23, 2021 at 09:59:26PM +0100, Andrew Cooper wrote:
> > 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.
> I think this could be problematic for identity mapped Arm dom0, as
> IIRC in that case grants are mapped so that gfn == mfn in order to
> account for the lack of an IOMMU. You could use a bounce buffer, but
> that would introduce a big performance penalty.
Or you could find a hole that is outside of the RAM regions. This is not 
trivial but not impossible (see [1]).
> Other question is whether we want/need to keep such mode going
> forward.
I am assunming by "such mode" you mean "identity mapped". If so, then I 
am afraid this is not going to disappear on Arm at least. There are 
still out there many platforms without IOMMUs or devices which are not 
protected (the GPU is a common one).
Furthermore, Arm just sent a series to introduce identity mapping for 
domUs as well (see [2]).
[1] <1631034578-12598-1-git-send-email-olekstysh@xxxxxxxxx>
[2] <20210923031115.1429719-1-penny.zheng@xxxxxxx>

Cheers,

--
Julien Grall