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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

>
> 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?

~Andrew

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