On Tue, 2011-05-10 at 16:27 +0100, Konrad Rzeszutek Wilk wrote:
> 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.
I'm not concerned with the ballooned case, I'm thinking of the normal
"boot with all memory" case. If the builder has populated 0..4G with RAM
but the E820 says 0..3G,4G..5G (i.e. an IO hole at 3G..4G) then somebody
must move the mfns from pfn-space 3G..4G to 4G..5G, mustn't they? Or at
least deallocate the ones in 3G..4G so that ballooning will subsequently
take over.
> 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.
Thanks.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home