From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH 1/5] xen: use maximum reservation to limit amount of usable RAM
Date: Thu, 1 Sep 2011 09:14:37 -0400 [thread overview]
Message-ID: <20110901131437.GA23971@dumpdata.com> (raw)
In-Reply-To: <4E5F769A.5080303@citrix.com>
> > 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 :-)
next prev parent reply other threads:[~2011-09-01 13:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-19 14:57 xen: memory initialization/balloon fixes (#2) David Vrabel
2011-08-19 14:57 ` [PATCH 1/5] xen: use maximum reservation to limit amount of usable RAM David Vrabel
2011-08-31 20:40 ` Konrad Rzeszutek Wilk
2011-09-01 12:12 ` David Vrabel
2011-09-01 13:14 ` Konrad Rzeszutek Wilk [this message]
2011-08-19 14:57 ` [PATCH 2/5] xen/balloon: account for pages released during memory setup David Vrabel
2011-09-06 21:31 ` Konrad Rzeszutek Wilk
2011-09-08 15:01 ` David Vrabel
2011-08-19 14:57 ` [PATCH 3/5] xen: allow balloon driver to use more than one memory region David Vrabel
2011-09-06 21:57 ` Konrad Rzeszutek Wilk
2011-09-07 10:44 ` David Vrabel
2011-09-07 18:09 ` Konrad Rzeszutek Wilk
2011-08-19 14:57 ` [PATCH 4/5] xen: allow extra memory to be in multiple regions David Vrabel
2011-09-07 12:28 ` Konrad Rzeszutek Wilk
2011-08-19 14:57 ` [PATCH 5/5] xen: release all pages within 1-1 p2m mappings David Vrabel
2011-08-19 15:05 ` David Vrabel
2011-09-06 21:20 ` Konrad Rzeszutek Wilk
2011-09-07 11:03 ` David Vrabel
2011-09-07 18:23 ` Konrad Rzeszutek Wilk
2011-08-22 14:49 ` xen: memory initialization/balloon fixes (#2) Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110901131437.GA23971@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).