Re: [Xen-devel] [PATCH v9 08/27] arm/x86/vmap: Add v[z|m]alloc_xen and vm_init_type

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.04.16 at 15:46, <konrad@xxxxxxxxxx> wrote:
> Then this should be perfect:

Almost.

> From cef95bc0682f94ca5e61609211c4787491212acf Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> Date: Tue, 26 Apr 2016 14:03:06 -0400
> Subject: [PATCH] arm/x86/vmap: Add vmalloc_xen and vm_init_type
> 
> For those users who want to use the virtual addresses that
> are in the hypervisor's code/data region address space -
> these three new functions allow that.
> 
> 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 vmzalloc_xen to utilize
> it (vfree and vunmap are capable of searching both address spaces).
> 
> 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 (on x86) (max displacement hence
> is 2GB virtual space, ARM32 is 128MB). 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.
> 
> Part of this patch also removes 'vm_alloc' and 'vm_free'
> decleration as we do not have any users of it.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> Suggested-by: Jan Beulich <jbeulich@xxxxxxxx>
> Acked-by: Julien Grall <julien.grall@xxxxxxx> [ARM]

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
with ...

>  void vunmap(const void *va)
>  {
>  #ifndef _PAGE_NONE
>      unsigned long addr = (unsigned long)va;
> +#endif

... the #ifndef here gone and ...

> +    unsigned int pages = vm_size(va, VMAP_DEFAULT);
> +
> +    if ( !pages )
> +        pages = vm_size(va, VMAP_XEN);
>  
> -    destroy_xen_mappings(addr, addr + PAGE_SIZE * vm_size(va));
> +#ifndef _PAGE_NONE
> +    destroy_xen_mappings(addr, addr + PAGE_SIZE * pages);
>  #else /* Avoid tearing down intermediate page tables. */
> -    map_pages_to_xen((unsigned long)va, 0, vm_size(va), _PAGE_NONE);
> +    map_pages_to_xen((unsigned long)va, 0, pages, _PAGE_NONE);

addr used here.

Thanks, Jan


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