From: Marcelo Tosatti <mtosatti@redhat.com>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: kvm@vger.kernel.org
Subject: Re: cr3 OOS optimisation breaks 32-bit GNU/kFreeBSD guest
Date: Fri, 20 Mar 2009 20:14:05 -0300 [thread overview]
Message-ID: <20090320231405.GA26415@amt.cnet> (raw)
In-Reply-To: <20090223003305.GW12976@hall.aurel32.net>
On Mon, Feb 23, 2009 at 01:33:05AM +0100, Aurelien Jarno wrote:
> Hi,
>
> Since kvm-81, I have noticed that GNU/kFreeBSD 32-bit guest are crashing
> under high load (during a compilation for example) with the following
> error message:
>
> | Fatal trap 12: page fault while in kernel mode
> | fault virtual address = 0x4
> | fault code = supervisor read, page not present
> | instruction pointer = 0x20:0xc0a4fc00
> | stack pointer = 0x28:0xe66d7a70
> | frame pointer = 0x28:0xe66d7a80
> | code segment = base 0x0, limit 0xfffff, type 0x1b
> | = DPL 0, pres 1, def32 1, gran 1
> | processor eflags = interrupt enabled, resume, IOPL = 0
> | current process = 24037 (bash)
> | trap number = 12
> | panic: page fault
> | Uptime: 4m7s
> | Cannot dump. No dump device defined.
> | Automatic reboot in 15 seconds - press a key on the console to abort
Aurelien,
Can you try this patch please.
-------
KVM: MMU: do not allow unsync global pages to become unreachable
Section 5.1 of the Intel TLB doc:
"• INVLPG. This instruction takes a single operand, which is a linear
address. The instruction invalidates any TLB entries for the page number
of that linear address including those for global pages (see Section
7). INVLPG also invalidates all entries in all paging-structure caches
regardless of the linear addresses to which they correspond."
Section 7:
"The following items detail the invalidation of global TLB entries:
• An execution of INVLPG invalidates any TLB entries for the page
number of the linear address that is its operand, even if the entries
are global."
If an unsync global page becomes unreachable via the shadow tree, which
can happen if one its parent pages is zapped, invlpg will fail to
invalidate translations for gvas contained in such unreachable pages.
So invalidate all unsync global entries when zapping a page. Another
possibility would be to cover global pages in the unsync bitmaps, but
that would increase overhead for mmu_sync_roots.
Index: kvm/arch/x86/kvm/mmu.c
===================================================================
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
@@ -1362,6 +1362,16 @@ static void kvm_mmu_unlink_parents(struc
}
}
+static void mmu_invalidate_unsync_global(struct kvm *kvm)
+{
+ struct kvm_mmu_page *sp, *n;
+
+ list_for_each_entry_safe(sp, n, &kvm->arch.oos_global_pages, oos_link) {
+ kvm_mmu_page_unlink_children(kvm, sp);
+ kvm_unlink_unsync_page(kvm, sp);
+ }
+}
+
static int mmu_zap_unsync_children(struct kvm *kvm,
struct kvm_mmu_page *parent)
{
@@ -1384,6 +1394,8 @@ static int mmu_zap_unsync_children(struc
kvm_mmu_pages_init(parent, &parents, &pages);
}
+ mmu_invalidate_unsync_global(kvm);
+
return zapped;
}
next prev parent reply other threads:[~2009-03-20 23:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-23 0:33 cr3 OOS optimisation breaks 32-bit GNU/kFreeBSD guest Aurelien Jarno
2009-02-23 1:47 ` Marcelo Tosatti
2009-02-23 14:01 ` Aurelien Jarno
2009-02-23 14:52 ` Marcelo Tosatti
2009-02-23 14:59 ` Avi Kivity
2009-02-23 15:06 ` Marcelo Tosatti
2009-02-23 15:16 ` Avi Kivity
2009-03-20 23:14 ` Marcelo Tosatti [this message]
2009-03-21 8:51 ` Aurelien Jarno
2009-03-22 9:35 ` Avi Kivity
2009-03-23 17:27 ` Marcelo Tosatti
2009-03-24 9:47 ` Avi Kivity
2009-03-24 11:49 ` Marcelo Tosatti
2009-04-03 21:45 ` Marcelo Tosatti
2009-04-04 10:37 ` Avi Kivity
2009-04-04 17:01 ` Marcelo Tosatti
2009-04-05 8:41 ` Avi Kivity
2009-04-05 11:29 ` Marcelo Tosatti
2009-04-05 11:41 ` Avi Kivity
2009-04-04 23:23 ` Aurelien Jarno
2009-03-24 10:39 ` Aurelien Jarno
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=20090320231405.GA26415@amt.cnet \
--to=mtosatti@redhat.com \
--cc=aurelien@aurel32.net \
--cc=kvm@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox