[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/5] xen/netback: Use xenballooned pages for comms
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@xxxxxxxxxxxxx> >>>> --- > [...] >>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |