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

[Andrew Cooper <andrew.cooper3@citrix.com>]

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