Re: [Xen-devel] [PATCH] xen/arm: Implement domain_get_maximum_gpfn

[Julien Grall <julien.grall@xxxxxxxxxx>]

(Adding Roger)

On 02/07/14 10:22, Ian Campbell wrote:
> On Wed, 2014-07-02 at 10:19 +0100, Julien Grall wrote:
>> Hi Ian,
>>
>> On 02/07/14 10:12, Ian Campbell wrote:
>>> On Tue, 2014-07-01 at 15:57 +0100, Julien Grall wrote:
>>>> The function domain_get_maximum_gpfn is returning the maximum gpfn ever
>>>> mapped in the guest. We can use d->arch.p2m.max_mapped_gfn for this 
>>>> purpose.
>>>
>>> What is using the result of this hypercall?
>>
>> The result is at least used by xc_dom_gnttab_hvm_seed, to get a scratch
>> GFN to initialize grant table.
>>
>> IHMO this is buggy on ARM (and x86?), because we could have map
>> everything up to the end of the address space (currently 40 bits).
> 
> I wonder if we could find a way to not need this hypercall at all.
> 
> Any reason why both arm and x86 can't just use a fixed scratch pfn for
> this temporary mapping? Both of them surely have spaces which they can
> guarantee won't overlap with anything.

This was the previous behavior until last November.

commit db062c28f30eb68d1b5d7a910445a0ba1136179a
Date:   Wed Nov 13 09:26:13 2013 +0100

    libxc: move temporary grant table mapping to end of memory
    
    In order to set up the grant table for HVM guests, libxc needs to map
    the grant table temporarily.  At the moment, it does this by adding the
    grant page to the HVM guest's p2m table in the MMIO hole (at gfn 0xFFFFE),
    then mapping that gfn, setting up the table, then unmapping the gfn and
    removing it from the p2m table.
    
    This breaks with PVH guests with 4G or more of ram, because there is
    no MMIO hole; so it ends up clobbering a valid RAM p2m entry, then
    leaving a "hole" when it removes the grant map from the p2m table.
    Since the guest thinks this is normal ram, when it maps it and tries
    to access the page, it crashes.
    
    This patch maps the page at max_gfn+1 instead.

I'm not sure what to do for x86, so I was planning to introduce a per-arch hook 
to retrieve a scratch gpfn.
x86 would keep the current behavior, and ARM will use the GNTTAB space in the 
layout.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel