From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 1/5] xen: use maximum reservation to limit amount of usable RAM Date: Thu, 1 Sep 2011 13:12:10 +0100 Message-ID: <4E5F769A.5080303@citrix.com> References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-2-git-send-email-david.vrabel@citrix.com> <20110831204057.GA641@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110831204057.GA641@dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 31/08/11 21:40, Konrad Rzeszutek Wilk wrote: >> Signed-off-by: David Vrabel >> --- >> arch/x86/xen/setup.c | 19 +++++++++++++++++++ >> 1 files changed, 19 insertions(+), 0 deletions(-) >> >> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c >> index df118a8..c3b8d44 100644 >> --- a/arch/x86/xen/setup.c >> +++ b/arch/x86/xen/setup.c >> @@ -184,6 +184,19 @@ static unsigned long __init xen_set_identity(const struct e820entry *list, >> PFN_UP(start_pci), PFN_DOWN(last)); >> return identity; >> } >> + >> +static unsigned long __init xen_get_max_pages(void) >> +{ >> + unsigned long max_pages = MAX_DOMAIN_PAGES; >> + domid_t domid = DOMID_SELF; >> + int ret; >> + >> + ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid); >> + if (ret > 0) >> + max_pages = ret; >> + return min(max_pages, MAX_DOMAIN_PAGES); >> +} >> + >> /** >> * machine_specific_memory_setup - Hook for machine specific memory setup. >> **/ >> @@ -292,6 +305,12 @@ char * __init xen_memory_setup(void) >> >> sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); >> >> + extra_limit = xen_get_max_pages(); >> + if (extra_limit >= max_pfn) >> + extra_pages = extra_limit - max_pfn; >> + else >> + extra_pages = 0; >> + >> extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); > > I ran this on three setups: > > 1) PV (domU) > 2) PV+PCI (dom0) > 3) PV+PCI+e820_hole=1 (domU) > > and then the same without this patch. > > Both the 2) and 3) worked correctly - the E820 had the same non-RAM regions and > gaps - and the last RAM E820 entry was properly truncated. However, when it > came to pure PV it was truncated more than it should: > > domU: domU: > 0000000000000000 - 00000000000a0000 (usable) 0000000000000000 - 00000000000a0000 (usable) > 00000000000a0000 - 0000000000100000 (reserved) 00000000000a0000 - 0000000000100000 (reserved) > 0000000000100000 - 0000000040800000 (usable) | 0000000000100000 - 0000000040100000 (usable) > > (left has the old PV - without your patch). Which makes me think that there is something > amiss in the toolstack? I used 'xl' (latest xen-unstable from today). What were you expecting? It looks like xl is either: specifying a memory map that is larger than it should be or b) setting the maximum reservation as too low. And if you asked for 1 GiB neither looks right. David