From: Ingo Molnar <mingo@elte.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Chris Lalancette <clalance@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] xen: Fix Xen domU boot with batched mprotect
Date: Mon, 27 Oct 2008 14:11:43 +0100 [thread overview]
Message-ID: <20081027131143.GA25371@elte.hu> (raw)
In-Reply-To: <49011979.8060301@goop.org>
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> From: Chris Lalancette <clalance@redhat.com>
>
> Recent i686 2.6.27 kernels with a certain amount of memory (between
> 736 and 855MB) have a problem booting under a hypervisor that
> supports batched mprotect (this includes the RHEL-5 Xen hypervisor
> as well as any 3.3 or later Xen hypervisor). The problem ends up
> being that xen_ptep_modify_prot_commit() is using virt_to_machine to
> calculate which pfn to update. However, this only works for pages
> that are in the p2m list, and the pages coming from
> change_pte_range() in mm/mprotect.c are kmap_atomic pages. Because
> of this, we can run into the situation where the lookup in the p2m
> table returns an INVALID_MFN, which we then try to pass to the
> hypervisor, which then (correctly) denies the request to a totally
> bogus pfn.
>
> The right thing to do is to use arbitrary_virt_to_machine, so that
> we can be sure we are modifying the right pfn. This unfortunately
> introduces a performance penalty because of a full page-table-walk,
> but we can avoid that penalty for pages in the p2m list by checking
> if virt_addr_valid is true, and if so, just doing the lookup in the
> p2m table.
>
> The attached patch implements this, and allows my 2.6.27 i686 based
> guest with 768MB of memory to boot on a RHEL-5 hypervisor again.
> Thanks to Jeremy for the suggestions about how to fix this
> particular issue.
>
> Signed-off-by: Chris Lalancette <clalance@redhat.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
> arch/x86/xen/mmu.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
applied to tip/x86/urgent, thanks!
Ingo
prev parent reply other threads:[~2008-10-27 13:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-24 0:40 [PATCH] xen: Fix Xen domU boot with batched mprotect Jeremy Fitzhardinge
2008-10-27 13:11 ` Ingo Molnar [this message]
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=20081027131143.GA25371@elte.hu \
--to=mingo@elte.hu \
--cc=clalance@redhat.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.