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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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.

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.

Regards,

-- 
Julien Grall

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