[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?



Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.