Re: [PATCH 1/5] xen/netback: Use xenballooned pages for comms

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 10/19/2011 12:32 PM, David Vrabel wrote:
> On 19/10/11 16:01, Daniel De Graaf wrote:
>> On 10/19/2011 05:04 AM, Ian Campbell wrote:
>>> On Tue, 2011-10-18 at 21:26 +0100, Daniel De Graaf wrote:
>>>> For proper grant mappings, HVM guests require pages allocated using
>>>> alloc_xenballooned_pages instead of alloc_vm_area.
>>>>
>>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>> ---
> [...]
>>> Could you also explain where the requirement to use xenballooned pages
>>> and not alloc_vm_area comes from in your commit message.
>>
>> (Will move to commit message). In PV guests, it is sufficient to only
>> reserve kernel address space for grant mappings because Xen modifies the
>> mappings directly. HVM guests require that Xen modify the GFN-to-MFN
>> mapping, so the pages being remapped must already be allocated. Pages
>> obtained from alloc_xenballooned_pages have valid GFNs not currently
>> mapped to an MFN, so are available to be used in grant mappings.
> 
> Why doesn't (or can't?) Xen add new entries to the GFN-to-MFN map?  Or
> why hasn't it reserved a range of GFNs in the map for this?
> 
> David
> 

That would be another way for Xen to solve this, but it would require
that the reserved GFN range be large enough for all mappings the guest
does, and would also need to be managed by the hypervisor. By allowing
the guest to specify which GFN to remap in the grant operation, the
guest can use any of the memory was either not populated at startup or
was returned to the hypervisor via XENMEM_decrease_reservation. For
32-bit guests with highmem, this also allows the guest to choose if the
grant-mapped pages are in high or low memory rather than forcing it to
be where the reserved GFN range ended up. Such a change would also
break API compatibility since the guest would need to read GFNs back
from the grant operation and map those GFNs.

-- 
Daniel De Graaf
National Security Agency