On Tue, May 10, 2011 at 04:09:58PM +0100, Ian Campbell wrote:
> On Tue, 2011-05-10 at 15:53 +0100, Konrad Rzeszutek Wilk wrote:
> > > > > > This has been tested with 2.6.18 (RHEL5), 2.6.27(SLES11), 2.6.36,
> > > > > > 2.6.37, 2.6.38,
> > > > > > and 2.6.39 kernels. Also tested with PV NetBSD 5.1.
> > >
> > > They all saw the full amount of RAM? Since the domain builder does not
> > Correct. So if the guest had 6GB passed in, roughly 3GB ended below the
> > 4GB mark, and then rest - 3GB got stuck behind the 4GB.
> Do you happen to know what caused that to work? I wasn't aware of any
> code which moved the p2m around based on e820 in older guests (and I
> can't find any right now) and I didn't think the builder itself paid any
> attention to the e820 either.
Correct. The build does not pay any attention to it. But the Xen setup code
in the older kernels (or perhaps it is the balloon code itself), does inflate
back to what was deflated. The PVOPS did not do that (argh, I didn't say
that in the earlier email - sorry about misleading you about that).
But just to make sure I am not feeding false information let me re-run this
with an RHEL5 guest and double-check.
Xen-devel mailing list