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. > > 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
