qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 */

      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).