From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: dom0 PVH: Over-allocation for domain 0: 393217 > 393216 Date: Wed, 4 Jun 2014 12:48:49 +0200 Message-ID: <538EF991.1080809@citrix.com> References: <1455607114.20140603141117@eikelenboom.it> <20140603122827.47f4e1c2@mantra.us.oracle.com> <20140603164949.74f4eab4@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ws8kc-0001qZ-Ry for xen-devel@lists.xenproject.org; Wed, 04 Jun 2014 10:48:59 +0000 In-Reply-To: <20140603164949.74f4eab4@mantra.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Mukesh Rathor , Sander Eikelenboom Cc: xen-devel@lists.xenproject.org, David Vrabel , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 04/06/14 01:49, Mukesh Rathor wrote: > On Tue, 3 Jun 2014 12:28:27 -0700 > Mukesh Rathor wrote: > = >> On Tue, 3 Jun 2014 14:11:17 +0200 >> Sander Eikelenboom wrote: >> >>> Hi, >>> >>> I just tried booting with "dom0pvh" and found the following warnings >>> (complete combined xl-dmesg/dmesg attached) which don't show up when >>> booting without dom0pvh: >> >> Yeah, I see. I'm able to reproduce. Something about >> dom0_mem=3D1536M,max:1536M ie, specifying max in there. Without it, >> dom0_mem=3D1536M, its fine. You can do that to play around more while I >> take a look. > = > Ok, I know whats going on. Basically, we are trying to populate the > pfns removed due to punched holes in the e820, but because max is > specified (same as initial ram), guest_physmap_add_page can't add. > = > This will be fixed by the e820 work that Roger and David Vrabel are = > doing. Please keep an eye on the thread: > = > http://www.gossamer-threads.com/lists/xen/devel/332603 Hello, I've been looking into this, and commented on David's patch: http://lists.xenproject.org/archives/html/xen-devel/2014-06/msg00293.html I'm also appending a modified version of patch 1, so you can apply it = directly. It seems to work fine in all my test cases (no dom0_mem, = dom0_mem=3D and dom0_mem=3D,max:). --- commit f503c114f86d92036e1af4e4246550f15e85c4bb Author: David Vrabel Date: Tue Jun 3 09:13:43 2014 +0200 x86/xen: fix memory setup for PVH dom0 = 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 Signed-off-by: Roger Pau Monn=E9 diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 201d09a..4e7d2b7 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1536,7 +1536,10 @@ asmlinkage void __init xen_start_kernel(void) if (!xen_pvh_domain()) pv_cpu_ops =3D xen_cpu_ops; = - x86_init.resources.memory_setup =3D xen_memory_setup; + if (xen_feature(XENFEAT_auto_translated_physmap)) + x86_init.resources.memory_setup =3D xen_auto_xlated_memory_setup; + else + x86_init.resources.memory_setup =3D xen_memory_setup; x86_init.oem.arch_setup =3D xen_arch_setup; x86_init.oem.banner =3D xen_banner; = diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 0982233..e6e9df8 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -509,6 +509,34 @@ 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 =3D E820MAX; + set_xen_guest_handle(memmap.buffer, map); + + rc =3D HYPERVISOR_memory_op(XENMEM_memory_map, &memmap); + BUG_ON(rc); + + sanitize_e820_map(map, ARRAY_SIZE(map), &memmap.nr_entries); + + for (i =3D 0; i < memmap.nr_entries; i++) + e820_add_region(map[i].addr, map[i].size, map[i].type); + + memblock_reserve(__pa(xen_start_info->mfn_list), + xen_start_info->pt_base - xen_start_info->mfn_list); + + 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);