[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] x86/xen: fix memory setup for PVH dom0



On 02/06/14 19:09, David Vrabel wrote:
> Since af06d66ee32b (x86: fix setup of PVH Dom0 memory map) in Xen, PVH
> dom0 need only use the memory memory provided by Xen which has already
> setup all the correct holes.
> 
> xen_memory_setup() then ends up being trivial for a PVH guest so
> introduce a new function (xen_auto_xlated_memory_setup()).
> 
> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>


Hello,

Thanks for the patch, as Mukesh pointed out, this is not working as-is.

> ---
>  arch/x86/xen/enlighten.c |    5 ++++-
>  arch/x86/xen/setup.c     |   23 +++++++++++++++++++++++
>  arch/x86/xen/xen-ops.h   |    1 +
>  3 files changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index c34bfc4..7dffa8c 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1536,7 +1536,10 @@ asmlinkage __visible void __init xen_start_kernel(void)
>       if (!xen_pvh_domain())
>               pv_cpu_ops = xen_cpu_ops;
>  
> -     x86_init.resources.memory_setup = xen_memory_setup;
> +     if (xen_feature(XENFEAT_auto_translated_physmap))
> +             x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
> +     else
> +             x86_init.resources.memory_setup = xen_memory_setup;
>       x86_init.oem.arch_setup = xen_arch_setup;
>       x86_init.oem.banner = xen_banner;
>  
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 0982233..e7ef388 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -509,6 +509,29 @@ char * __init xen_memory_setup(void)
>  }
>  
>  /*
> + * Machine specific memory setup for auto-translated guests.
> + */
> +char * __init xen_auto_xlated_memory_setup(void)
> +{
> +     static struct e820entry map[E820MAX] __initdata;
> +
> +     struct xen_memory_map memmap;
> +     int i;
> +     int rc;
> +
> +     memmap.nr_entries = E820MAX;
> +     set_xen_guest_handle(memmap.buffer, map);
> +
> +     rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
> +     BUG_ON(rc);

Although not strictly necessary, I think it would be good to add the
following here (it's also done in bare metal Linux):

sanitize_e820_map(map, ARRAY_SIZE(map), &memmap.nr_entries);

> +
> +     for (i = 0; i < memmap.nr_entries; i++)
> +             e820_add_region(map[i].addr, map[i].size, map[i].type);

And I think here we need to reserve the start_info area:

memblock_reserve(__pa(xen_start_info->mfn_list),
        xen_start_info->pt_base - xen_start_info->mfn_list);

With those changes I've been able to boot fine, but I'm still testing.

> +     return "Xen";
> +}
> +
> +/*
>   * Set the bit indicating "nosegneg" library variants should be used.
>   * We only need to bother in pure 32-bit mode; compat 32-bit processes
>   * can have un-truncated segments, so wrapping around is allowed.
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index 1cb6f4c..b371d18 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -34,6 +34,7 @@ extern unsigned long xen_max_p2m_pfn;
>  void xen_set_pat(u64);
>  
>  char * __init xen_memory_setup(void);
> +char * xen_auto_xlated_memory_setup(void);
>  void __init xen_arch_setup(void);
>  void xen_enable_sysenter(void);
>  void xen_enable_syscall(void);
> 


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.