From: "andrzej zaborowski" <balrogg@gmail.com>
To: Qemu mailing list <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: [kqemu] gpf in memory access
Date: Mon, 4 Feb 2008 00:53:54 +0100 [thread overview]
Message-ID: <fb249edb0802031553x66c2ddfcrb136a24d4f1e9516@mail.gmail.com> (raw)
In-Reply-To: <fb249edb0802030846o437a1ac8u50663d8b9713d3ab@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
Ok, here's a patch that also makes -kernel-kqemu behave (with the
previous patch it would abort with a "triple fault").
Due to the way kqemu sets up the mmu there should never be a GP fault
in the mem access operations, so it would normally indicate some
breakage and kqemu correctly aborts. However I looked it up in the
amd64 specs and there can be a GP fault in a memory access when the
sign extend bits ([63:52]) of the address are not in "canonical form"
(for instance 0xff00000000000000 is not in canonical form). This patch
will make such a GPF be reported to qemu. The patch only affects the
x86-64 on x86-64 case.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: kqemu-mem-gpf-amd64.patch --]
[-- Type: text/x-patch; name=kqemu-mem-gpf-amd64.patch, Size: 1508 bytes --]
diff --git a/common/common.c b/common/common.c
index 285b072..29443ce 100644
--- a/common/common.c
+++ b/common/common.c
@@ -242,7 +242,7 @@ static inline uint64_t *mon_get_ptep_l3(struct kqemu_state *s,
if (!(pml4e & PG_PRESENT_MASK)) {
if (!alloc)
return NULL;
- /* allocage a new page */
+ /* allocate a new page */
ptr = mon_alloc_page(s, &pdp_page_index);
if (!ptr)
return NULL;
diff --git a/common/kqemu_int.h b/common/kqemu_int.h
index d881d85..b2f0b6e 100644
--- a/common/kqemu_int.h
+++ b/common/kqemu_int.h
@@ -1065,6 +1065,9 @@ static inline void stq_fast(struct kqemu_state *s, unsigned long addr,
#define MMU_EXCEPTION(label) \
".section \"mmu_ex_table\", \"a\"\n"\
".quad " #label "\n"\
+ ".previous\n"\
+ ".section \"seg_ex_table\", \"a\"\n"\
+ ".quad " #label "\n"\
".previous\n"
#else
#define MMU_EXCEPTION(label) \
diff --git a/common/monitor.c b/common/monitor.c
index ed46845..b3b72dc 100644
--- a/common/monitor.c
+++ b/common/monitor.c
@@ -1515,6 +1515,10 @@ static void handle_mon_exception(struct kqemu_state *s,
/* division exception from interp */
/* XXX: verify for fxsave/fxrstor */
s->regs = &s->regs1;
+#ifdef __x86_64__
+ } else if (intno == 0x0d && expected_monitor_exception(pc)) {
+ raise_exception(s, KQEMU_RET_SOFTMMU);
+#endif
} else {
/* Note: the exception state is reliable only for goto_user
handling */
prev parent reply other threads:[~2008-02-03 23:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-03 16:46 [Qemu-devel] [kqemu] gpf in memory access andrzej zaborowski
2008-02-03 23:53 ` andrzej zaborowski [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=fb249edb0802031553x66c2ddfcrb136a24d4f1e9516@mail.gmail.com \
--to=balrogg@gmail.com \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).