From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 1/5] xen: use maximum reservation to limit amount of usable RAM Date: Thu, 1 Sep 2011 09:14:37 -0400 Message-ID: <20110901131437.GA23971@dumpdata.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> <4E5F769A.5080303@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4E5F769A.5080303@citrix.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: David Vrabel Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org > > 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. 'xm' is even worst. It ends up truncating it to 40000000 exactly. Anyhow, I chatted with Ian about it and also the thread "difference between xen hypervisor and common kernel on handling BIOS's e820 map" nails the coffin to this - there is no need anymore for that 8MB of extra space. So - off to look at your next set of patches :-)