| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home