Re: [Xen-devel] [PATCH] libxc: introduce a per architecture scratch pfn for temporary grant mapping

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 14/01/15 13:23, Andrew Cooper wrote:
> On 14/01/15 13:20, Julien Grall wrote:
>> On 14/01/15 12:58, Andrew Cooper wrote:
>>> On 13/01/15 20:10, Julien Grall wrote:
>>>> The code to initialize the grant table in libxc uses
>>>> xc_domain_maximum_gpfn() + 1 to get a guest pfn for mapping the grant
>>>> frame and to initialize it.
>>>>
>>>> This solution has two major issues:
>>>>     - The check of the return of xc_domain_maximum_gpfn is buggy because
>>>>     xen_pfn_t is unsigned and in case of an error -ERRNO is returned.
>>>>     Which is never catch with ( pfn <= 0 ).
>>> Wow - xc_domain_maximum_gpfn() will currently truncate long to int on
>>> 64bit systems.  That is unhelpful of it.
>>>
>>>>     - The guest memory layout maybe filled up to the end, i.e
>>>>     xc_domain_maximum_gpfn() + 1 gives either 0 or an invalid PFN due to
>>>>     hardware limitation.
>>> I realise I am throwing a spanner in the works here, but if you are
>>> looking to fix it, lets fix this properly rather than hacking around the
>>> problem further.
>>>
>>> There is currently no way for the toolstack to map something on behalf
>>> of a guest which is not in the guest physmap.  As a workaround, the code
>>> here shoots a guest ram page, adds a non-ram page to the physmap, maps,
>>> edits, unmaps and replaces the ram.
>> Hmmm... why do you talk about shooting a guest RAM page? Neither the
>> current code, nor the suggested solution for ARM does a such things.
> 
> That is what x86 does.  I assumed (clearly incorrectly) that ARM was
> similar.

Are you sure? With xc_domain_maximum_gpfn() + 1 we should not shoot a
RAM page. At least most of the time.

>>
>> ARM is defining a grant table range which is out of the RAM and not
>> mapped at that time. So we can reuse it with any possible issue.
> 
> Do you mean to say that there is a grant table range baked into the ABI
> occupying guest physical address space?

Yes.

Regards,

-- 
Julien Grall

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