public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>, mingo@elte.hu
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	hpa@linux.intel.com, hpa@zytor.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: Linux 2.6.39-rc7
Date: Tue, 10 May 2011 19:36:44 -0400	[thread overview]
Message-ID: <20110510233644.GA23858@dumpdata.com> (raw)
In-Reply-To: <20110510035356.GA6954@dumpdata.com>

On Mon, May 09, 2011 at 11:53:56PM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, May 09, 2011 at 07:49:48PM -0700, Linus Torvalds wrote:
> > So things have been pretty quiet, and unless something major comes up
> > I believe that this will be the last -rc.
> 
> Oh no! I was hoping for an extra week!
> 
> The patch that I asked to be pulled: (a38647837a411f7df79623128421eef2118b5884)
> "xen/mmu: Add workaround "x86-64, mm: Put early page table high"
> 
> does not compleltly workaround the regression that the patch from Yinghai titled 
> 'x86-64, mm: Put early page table high" introduced wherein Linux can't boot under Xen.
> 
> The failure still encountered: https://lkml.org/lkml/2011/5/5/180, the
> previous git pull request with an outline of the problem https://lkml.org/lkml/2011/5/3/99
> and huge amount of details in http://marc.info/?i=1302607192-21355-2-git-send-email-stefano.stabellini@eu.citrix.com
> 
> I was hoping that the rc6 could stretch out so that by the time hpa came back from
> his travels he would have had a chance to look at: https://lkml.org/lkml/2011/5/5/226

I had a chance to briefly talk on IRC with hpa and he mentioned I should
send a note to Ingo about this since hpa won't be able to do anything until Friday.

Ingo,
Not sure how familiar you are with this issue, but let me briefly explain it.
Yinghai provided a patch, which calls memblock_find_in_range(), then calls
kernel_physical_mapping_init, which populates the pagetable between pgt_buf_start
and pgt_buf_top and once it is done, calls memblock_x86_reserve_range with pgt_buf_start
and pgt_buf_end (wherein pgt_buf_end <=  pgt_buf_top). The memory between pgt_buf_end
and pgt_buf_top can be re-used later on and it is by other subsystems - NUMA for
example uses it.

Under Xen, the pagetables end up being marked RO, so what ends up happening is that
some pages from pgt_buf_end through pgt_buf_top end up RO and the system crashes during
bootup as NUMA subsystem tries to write to that area. The fix is to essentially mark the
area from pgt_buf_end through pgt_buf_top to RW.

Stefano posted a patch, which was Acked by Yinghai, but not so by hpa. The concerns
were that the patch inserts a hook just for this single case and there should be a better
way of doing this - where we either don't need a hook or provide an semantic explanation
of the pagetable building and build the patch from there.

Sadly there was/is not enough time in the 2.6.39 train to actually do it properly.
So I provided another patch (which Linus merged) which crudely tries to mark the area from
pgt_buf_end through pgt_buf_top to RW and all is done within the Xen MMU code. Sadly it
does not work on all machines.

Without a resolution to this, the Linux x86_64 kernel cannot boot under Xen. There are two
options left right now:
 a). Revert 4b239f458c229de044d6905c2b0f9fe16ed9e01e (x86-64, mm: Put early page table high)
 b). or revert the workaround that Linus merged and pick the one that Stefano came up with.
     The patches are available in
     git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/bug-fixes-for-rc6

     They touch the generic x86 MMU code.


  reply	other threads:[~2011-05-10 23:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-10  2:49 Linux 2.6.39-rc7 Linus Torvalds
2011-05-10  3:53 ` Konrad Rzeszutek Wilk
2011-05-10 23:36   ` Konrad Rzeszutek Wilk [this message]
2011-05-10 23:42     ` H. Peter Anvin
2011-05-12 16:49 ` [2.6.39 regression] i915/kms: garbled screen because of 49183b281 (was: Re: Linux 2.6.39-rc7) Melchior FRANZ
2011-05-12 18:52   ` [PATCH] Revert "drm/i915: Only enable the plane after setting the fb base (pre-ILK)" Keith Packard
2011-05-12 21:41   ` [2.6.39 regression] i915/kms: garbled screen because of 49183b281 (was: Re: Linux 2.6.39-rc7) Chris Wilson
2011-05-13 11:59     ` Melchior FRANZ
2011-05-30 12:10   ` [3.0-rc1 regression] (was: Re: [2.6.39 regression] i915/kms: garbled screen because of 49183b281) Melchior FRANZ
2011-05-15 13:50 ` Linux 2.6.39-rc7 Borislav Petkov
2011-05-15 13:53   ` Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110510233644.GA23858@dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=hpa@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox