Re: [Xen-devel] [PATCH 5/7] xen/setup: Transfer MFNs from non-RAME820 entries and gaps to E820 RAM

[Konrad Rzeszutek Wilk]

On Tue, Apr 03, 2012 at 09:13:44AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 03, 2012 at 09:48:43AM +0100, David Vrabel wrote:
> > On 30/03/12 21:37, Konrad Rzeszutek Wilk wrote:
> > > We will now get:
> > > 
> > > -Released 283999 pages of unused memory
> > > +Exchanged 283999 pages
> > > .. snip..
> > > -Memory: 6487732k/9208688k available (5817k kernel code, 1136060k absent, 1584896k reserved, 2900k data, 692k init)
> > > +Memory: 6503888k/8072692k available (5817k kernel code, 1136060k absent, 432744k reserved, 2900k data, 692k init)
> > 
> > This isn't correct.  You've have lost ~1 GB of memory which are the
> > pages that were supposed to be moved.  The additional 1GB of reserved
> > memory in the old case is the balloon.
> 
> Whoops.
> > 
> > In xen_memory_setup() where it loops through the e820 to clip the RAM
> > regions you need to factor in the additional memory you've moved.  In
> > this loop you may need to count the pages in the RAM region instead of
> > the simple (addr < mem_end) test.  Take care with RAM regions with
> > partial pages and the like.
> 
> <nods> I did some more exhaustive testing and hit some issues

.. which is that moving the MFNs in the P2M is fine from the Linux kernel perspective
but the changes won't be reflected in the M2P. To make the M2P have the new
PFNs I have to use the populate_physmap hypercall.

A new-ish version will be posted soon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/