Re: [PATCH v7 06/24] arm/x86/vmap: Add vmalloc_xen, vfree_xen and vm_init_type

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Apr 11, 2016 at 10:39:59AM +0100, Andrew Cooper wrote:
> On 10/04/16 22:14, Konrad Rzeszutek Wilk wrote:
> > For those users who want to use the virtual addresses that
> > are in the hypervisor's virtual address space - these threej new
> 
> Technically, all space is "the hypervisor's".  Perhaps "the hypervisor's
> code/data region" instead?
> 
> Also, is this new threej something similar to three?
> 
> > functions allow that. Along with providing the underlaying
> > MFNs for the user's (such as changing page table permissions).
> 
> The MFNs are now not provided.

Duh. Yes indeed. Thank you!
> 
> >
> > Implementation wise the vmap API keeps track of two virtual
> > address regions now:
> >  a) VMAP_VIRT_START
> >  b) Any provided virtual address space (need start and end).
> >
> > The a) one is the default one and the existing behavior
> > for users of vmalloc, vmap, etc is the same.
> >
> > If however one wishes to use the b) one only has to use
> > the vm_init_type to initialize and the vmalloc_type to utilize it.
> >
> > This allows users (such as xSplice) to provide their own
> > mechanism to change the the page flags, and also use virtual
> > addresses closer to the hypervisor virtual addresses (at least
> > on x86) while not having to deal with the allocation of
> > pages.
> >
> > For example of users, see patch titled "xsplice: Implement payload
> > loading", where we parse the payload's ELF relocations - which
> > is defined to be signed 32-bit (so max displacement is 2GB virtual
> > spacE). The displacement of the hypervisor virtual addresses to the
> > vmalloc (on x86) is more than 32-bits - which means that ELF relocations
> > would truncate the 34 and 33th bit. Hence this alternate API.
> >
> > We also add add extra checks in case the b) range has not been initialized.
> >
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Suggested-by: Jan Beulich <jbeulich@suse.com>
> > Acked-by: Julien Grall <julien.grall@arm.com> [ARM]
> 
> Otherwise, much nicer than before.
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

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