This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH tip/x86/mm] x86_32: calculate additional memory n

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH tip/x86/mm] x86_32: calculate additional memory needed by the fixmap
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Wed, 20 Jul 2011 09:09:04 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, stefano.stabellini@xxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, hpa@xxxxxxxxx, mingo@xxxxxxx, hpa@xxxxxxxxxxxxxxx, yinghai@xxxxxxxxxx
Delivery-date: Wed, 20 Jul 2011 06:12:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20004.24417.577289.167313@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <m2n.s.1Qimoi-131463@xxxxxxxxxxxxxxxxxxxxxx> <20004.24417.577289.167313@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Jul 18, 2011 at 05:29:21PM +0100, Ian Jackson wrote:
> stefano.stabellini@xxxxxxxxxxxxx writes ("[Xen-devel] [PATCH tip/x86/mm] 
> x86_32: calculate additional memory needed by the fixmap"):
> > Unfortunately this code is rather complex and depends on the behaviour
> > of other functions but I hope to have covered all the corner cases.
> I'm sorry to say that think this is really the wrong approach.
> I agree that *some* change needs to be made, as this is currently a
> serious regression in tip/x86/mm.

tip/x86/mm should boot with this patch, right?

> But the correct change is in fact to undo the reversion of
>   "x86,xen: introduce x86_init.mapping.pagetable_reserve"
> That was a hook with a reasonable and defined interface.
> What we are having instead, now, is a fragile piece of code that tries
> to second-guess the complex config- and hardware-dependent
> memory-allocation behaviour of the rest of the startup code.  This is
> a recipe for making things break.

Stefano did an excellent job at doing an archaeological excavation
and finding all the little pieces and bringing them up to surface
via this function. We have now the full accounting of the early
bootup code and its page table creation. And based on that we can
tighten the dance between pgt_end/pgt_begin/pgt_top to WARN much
sooner - and I hope make the code more simpler.

Sure there are some bugs that we won't find until more folks start
testing it - I've only found this one b/c of playing with a bigger
set of .config variants. But that is part of the 3.1-rcX cycle - to
find them and fix them. Or if we cannot fix them, then revert this
whole patchset and think then some more - maybe at the Linux Plumbers
Conference or the Linux Kernel mini-summits.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>