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.w...@oracle.com> > > Suggested-by: Jan Beulich <jbeul...@suse.com> > > Acked-by: Julien Grall <julien.gr...@arm.com> [ARM] > > Otherwise, much nicer than before. > > Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
