Re: [Xen-devel] [RFC PATCH] page_alloc: use first half of higher order chunks when halving

[Matthew Rushton <mvrushton@xxxxxxxxx>]

On 05/23/14 12:00, Konrad Rzeszutek Wilk wrote:
> On Tue, May 20, 2014 at 12:26:57PM -0700, Matthew Rushton wrote:
> > On 05/14/14 08:06, Konrad Rzeszutek Wilk wrote:
> > > On Wed, May 07, 2014 at 04:16:14PM -0700, Matthew Rushton wrote:
> > > > On 04/16/14 07:15, Konrad Rzeszutek Wilk wrote:
> > > > > On Mon, Apr 14, 2014 at 04:34:47PM +0100, Jan Beulich wrote:
> > > > > > > > > On 14.04.14 at 16:40, <konrad.wilk@xxxxxxxxxx> wrote:
> > > > > > > That was OK, but the M2P lookup table was not too thrilled with this.
> > > > > > > Perhaps I should have used another hypercall to re-arrange the M2P?
> > > > > > > I think I did try 'XENMEM_exchange' but that is not the right call either.
> > > > > > Yeah, that's allocating new pages in exchange for your old ones. Not
> > > > > > really what you want.
> > > > > >
> > > > > > > Perhaps I should use XENMEM_remove_from_physmap/XENMEM_add_to_physmap
> > > > > > > combo ?
> > > > > > A pair of MMU_MACHPHYS_UPDATE operations would seem to be the
> > > > > > right way of doing this (along with respective kernel internal accounting
> > > > > > like set_phys_to_machine(), and perhaps a pair of update_va_mapping
> > > > > > operations if the 1:1 map is already in place at that time, and you care
> > > > > > about which page contents appears at which virtual address).
> > > > > OK.
> > > > >
> > > > > Matt & Matthew - my plate is quite filled and I fear that in the next three
> > > > > weeks there is not going to be much time to code up a prototype.
> > > > >
> > > > > Would either one of you be willing to take a crack at this? It would
> > > > > be neat as we could remove a lot of the balloon increase/decrease code
> > > > > in arch/x86/xen/setup.c.
> > > > >
> > > > > Thanks!
> > > > I have a first pass at this. Just need to test it and should have something
> > > > ready sometime next week or so.
> > > Daniel pointed me to this commit:
> > > ommit 2e2fb75475c2fc74c98100f1468c8195fee49f3b
> > > Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > > Date:   Fri Apr 6 10:07:11 2012 -0400
> > >
> > >      xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 
> > > RAM
> > > ..
> > >      The other solution (that did not work) was to transplant the MFN in
> > >      the P2M tree - the ones that were going to be freed were put in
> > >      the E820_RAM regions past the nr_pages. But the modifications to the
> > >      M2P array (the other side of creating PTEs) were not carried away.
> > >      As the hypervisor is the only one capable of modifying that and the
> > >      only two hypercalls that would do this are: the update_va_mapping
> > >      (which won't work, as during initial bootup only PFNs up to nr_pages
> > >      are mapped in the guest) or via the populate hypercall.
> > >
> > > Where I talk about the 'update_va_mapping' - and I seem to think
> > > that it would not work (due to the nr_pages limit). I don't actually
> > > remember the details - so I might have been incorrect (hopefully!?).
> > Ok I finally have something I'm happy with using the mmu_update hypercall
> > and placing things in the existing E820 map. I don't think the
> > update_va_mapping hypercall is necessary. It ended up being a little more
> > complicated than I originally thought to handle not allocating additional
> > p2m leaf nodes. I'm going on vacation here shortly and can post it when I
> > get back.
> Enjoy the vacation and I am looking forward to seeing the patches when you
> come back!
>
> Thank you!
Sent patch to lkml late last week ([PATCH] xen/setup: Remap Xen Identity 
Mapped RAM). Will cc xen-devel on further correspondance.
-Matt

> > > > > > Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel