On Thu, Aug 20, 2009 at 05:36:01PM +0100, Gianluca Guida wrote:
> Konrad Rzeszutek Wilk writes:
> > On Thu, Aug 20, 2009 at 04:49:08PM +0100, Gianluca Guida wrote:
> > > Konrad Rzeszutek Wilk writes:
> > > > I will retry this, but in the meantime I am tracking balloon
> accessing non-existent pages:
> > >
> > > Hm, what tree of dom0 kernel are you using? Is commit
> > [konrad@phenom linux]$ git checkout origin/rebase/master -b boo
> > Branch boo set up to track remote branch refs/remotes/origin/rebase/master.
> > Switched to a new branch 'boo'
> > [konrad@phenom linux]$ git show 7394b25905929a92e51771b832ee67b70ccebcf0
> > fatal: bad object 7394b25905929a92e51771b832ee67b70ccebcf0
> Ok, you don't have the revert, do you have
> a472909fe0e3b7bfa34f7c9dd748121b0ede0ee6 in your tree?
> > > 7394b25905929a92e51771b832ee67b70ccebcf0 (Revert "Xen: Allow guest to
> > > boot ballooned.") there?
> > What branch is it in?
> rebase/master, checked in last week.
Hmmm. Let me checkout a new tree and see why I am behind.
> > >
> > > The point is that xen_memory_setup should truncate the ram visible in
> > > the e820 map to xen_start_info->nr_pages, so that the balloon driver
> > > would never try to add pages on boot.
> > Sure. This problem is for pages above ->nr_pages.
> max_pfn is calculated by the e820 map, so there would be nothing above
> I was assuming you had an up-to-date tree, where there's no "Allow
> guest to boot ballooned" patch. When that patch is present no
> truncation happens, and you get hit by that bug, which your patch
Xen-devel mailing list