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

[Julien Grall <julien@xen.org>]

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@amazon.com>
>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>> ---
>>> You can find the related discussions at:
>>> https://lore.kernel.org/xen-devel/93d0df14-2c8a-c2e3-8c51-54412190171c@xen.org/
>>> https://lore.kernel.org/xen-devel/1628890077-12545-1-git-send-email-olekstysh@gmail.com/
>>> https://lore.kernel.org/xen-devel/1631652245-30746-1-git-send-email-olekstysh@gmail.com/
>>>
>>> ! 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@gmail.com>
[2] <20210923031115.1429719-1-penny.zheng@arm.com>

Cheers,

-- 
Julien Grall