From: David Wentzlaff <wentzlaf@cag.csail.mit.edu>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH] x86_64 Exception hardware checks incorrect bits of IDT entry
Date: Mon, 9 Jun 2008 21:03:22 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0806091838010.1320@uncle-of-god.csail.mit.edu> (raw)
When using an x86_64 client on QEMU, the function do_interrupt64 in
target-i386/op_helper.c (used to be called target-i386/helper.c) checks
bits in an IDT entry as if it was a segment descriptor. IDT entries are
not segment descriptors (but are similar) and it looks like this might
have been a copy and paste error from segment descriptor check logic.
Namely do_interrupt64 checks DESC_S_MASK, DESC_CS_MASK, DESC_L_MASK,
DESC_B_MASK, and DESC_C_MASK all of which are either in the Offset [31:16]
field of a 64-bit IDT entry or it checks bits which are in the second
word, but are used for the type of the IDT (whether it is a trap gate vs
interrupt gate). When these bits are not set appropriately, QEMU x86_64
erroneously throws a GPF. I am not sure how QEMU is capable of booting
any x86_64 operating system problem. The only thing I can think of is
that there was some very fortuitous alignment of common x86_64 OS's
interrupt vectors... Please check and review this change. The IDT entry
format on x86_64 can examined in Intel's x86 Software Developers Manual
Volume 3A page 5-23 figure 5-7.
The patch simply removes these erroneous checks and is below (note that
this diff is against the main trunk, but this problem existed in the last
release (0.9.1) also, but there it was in a file called
target-i386/helper.c.
Sincerely,
David Wentzlaff
----- Patch starts here -----
Index: target-i386/op_helper.c
===================================================================
--- target-i386/op_helper.c (revision 4716)
+++ target-i386/op_helper.c (working copy)
@@ -914,16 +914,12 @@
if (load_segment(&e1, &e2, selector) != 0)
raise_exception_err(EXCP0D_GPF, selector & 0xfffc);
- if (!(e2 & DESC_S_MASK) || !(e2 & (DESC_CS_MASK)))
- raise_exception_err(EXCP0D_GPF, selector & 0xfffc);
dpl = (e2 >> DESC_DPL_SHIFT) & 3;
if (dpl > cpl)
raise_exception_err(EXCP0D_GPF, selector & 0xfffc);
if (!(e2 & DESC_P_MASK))
raise_exception_err(EXCP0B_NOSEG, selector & 0xfffc);
- if (!(e2 & DESC_L_MASK) || (e2 & DESC_B_MASK))
- raise_exception_err(EXCP0D_GPF, selector & 0xfffc);
- if ((!(e2 & DESC_C_MASK) && dpl < cpl) || ist != 0) {
+ if ((dpl < cpl) || ist != 0) {
/* to inner privilege */
if (ist != 0)
esp = get_rsp_from_tss(ist + 3);
@@ -932,7 +928,7 @@
esp &= ~0xfLL; /* align stack */
ss = 0;
new_stack = 1;
- } else if ((e2 & DESC_C_MASK) || dpl == cpl) {
+ } else if (dpl == cpl) {
/* to same privilege */
if (env->eflags & VM_MASK)
raise_exception_err(EXCP0D_GPF, selector & 0xfffc);
reply other threads:[~2008-06-10 1:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=Pine.LNX.4.64.0806091838010.1320@uncle-of-god.csail.mit.edu \
--to=wentzlaf@cag.csail.mit.edu \
--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).