From: "Jan Beulich" <JBeulich@novell.com>
To: chrisw@osdl.org
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] x86_64 trap table fixup
Date: Mon, 04 Jul 2005 01:46:35 -0600 [thread overview]
Message-ID: <s2c894e1.027@lucius.provo.novell.com> (raw)
One remark since this code is getting touched now anyway: You appear to
have taken the same (somewhat broken) approach of handling #BR as Linux
does. Architecturally, IDT entry 5 should be a DPL=0 one (permitting
BOUND, but disallowing INT 05); is there any particular reason you want
to allow INT 05 here (which could get you in conflict with hosting
Windows, which appears to deal with this the architecture intended way)?
Jan
>>> Chris Wright <chrisw@osdl.org> 04.07.05 06:27:27 >>>
Recent header file cleanup (cset
2b6c1a8098078f7e53de7cf72227fddf01f0b2b6)
broke x86_64. The cleanup removed a padding field in trap_info_t, so
the
trap table set the address for each trap handler to zero.
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
diff -r f8acd354e129
linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/traps.c
--- a/linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/traps.c Sat Jul
2 08:41:48 2005
+++ b/linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/traps.c Sun Jul
3 23:18:10 2005
@@ -910,31 +910,31 @@
static trap_info_t trap_table[] = {
- { 0, 0, (__KERNEL_CS|0x3), 0, (unsigned long)divide_error
},
- { 1, 0, (__KERNEL_CS|0x3), 0, (unsigned long)debug
},
- { 3, 3, (__KERNEL_CS|0x3), 0, (unsigned long)int3
},
- { 4, 3, (__KERNEL_CS|0x3), 0, (unsigned long)overflow
},
- { 5, 3, (__KERNEL_CS|0x3), 0, (unsigned long)bounds
},
- { 6, 0, (__KERNEL_CS|0x3), 0, (unsigned long)invalid_op
},
- { 7, 0, (__KERNEL_CS|0x3), 0, (unsigned
long)device_not_available },
- { 9, 0, (__KERNEL_CS|0x3), 0, (unsigned
long)coprocessor_segment_overrun},
- { 10, 0, (__KERNEL_CS|0x3), 0, (unsigned long)invalid_TSS
},
- { 11, 0, (__KERNEL_CS|0x3), 0, (unsigned
long)segment_not_present },
- { 12, 0, (__KERNEL_CS|0x3), 0, (unsigned long)stack_segment
},
- { 13, 0, (__KERNEL_CS|0x3), 0, (unsigned
long)general_protection },
- { 14, 0, (__KERNEL_CS|0x3), 0, (unsigned long)page_fault
},
- { 15, 0, (__KERNEL_CS|0x3), 0, (unsigned
long)spurious_interrupt_bug },
- { 16, 0, (__KERNEL_CS|0x3), 0, (unsigned
long)coprocessor_error },
- { 17, 0, (__KERNEL_CS|0x3), 0, (unsigned long)alignment_check
},
+ { 0, 0, (__KERNEL_CS|0x3), (unsigned long)divide_error
},
+ { 1, 0, (__KERNEL_CS|0x3), (unsigned long)debug
},
+ { 3, 3, (__KERNEL_CS|0x3), (unsigned long)int3
},
+ { 4, 3, (__KERNEL_CS|0x3), (unsigned long)overflow
},
+ { 5, 3, (__KERNEL_CS|0x3), (unsigned long)bounds
},
+ { 6, 0, (__KERNEL_CS|0x3), (unsigned long)invalid_op
},
+ { 7, 0, (__KERNEL_CS|0x3), (unsigned
long)device_not_available },
+ { 9, 0, (__KERNEL_CS|0x3), (unsigned
long)coprocessor_segment_overrun},
+ { 10, 0, (__KERNEL_CS|0x3), (unsigned long)invalid_TSS
},
+ { 11, 0, (__KERNEL_CS|0x3), (unsigned long)segment_not_present
},
+ { 12, 0, (__KERNEL_CS|0x3), (unsigned long)stack_segment
},
+ { 13, 0, (__KERNEL_CS|0x3), (unsigned long)general_protection
},
+ { 14, 0, (__KERNEL_CS|0x3), (unsigned long)page_fault
},
+ { 15, 0, (__KERNEL_CS|0x3), (unsigned
long)spurious_interrupt_bug },
+ { 16, 0, (__KERNEL_CS|0x3), (unsigned long)coprocessor_error
},
+ { 17, 0, (__KERNEL_CS|0x3), (unsigned long)alignment_check
},
#ifdef CONFIG_X86_MCE
- { 18, 0, (__KERNEL_CS|0x3), 0, (unsigned long)machine_check
},
-#endif
- { 19, 0, (__KERNEL_CS|0x3), 0, (unsigned
long)simd_coprocessor_error },
- { SYSCALL_VECTOR, 3, (__KERNEL_CS|0x3), 0, (unsigned
long)system_call },
+ { 18, 0, (__KERNEL_CS|0x3), (unsigned long)machine_check
},
+#endif
+ { 19, 0, (__KERNEL_CS|0x3), (unsigned
long)simd_coprocessor_error },
+ { SYSCALL_VECTOR, 3, (__KERNEL_CS|0x3), (unsigned
long)system_call },
#ifdef CONFIG_IA32_EMULATION
- { IA32_SYSCALL_VECTOR, 3, (__KERNEL_CS|0x3), 0, (unsigned
long)ia32_syscall},
-#endif
- { 0, 0, 0, 0, 0
}
+ { IA32_SYSCALL_VECTOR, 3, (__KERNEL_CS|0x3), (unsigned
long)ia32_syscall},
+#endif
+ { 0, 0, 0, 0
}
};
void __init trap_init(void)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next reply other threads:[~2005-07-04 7:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-04 7:46 Jan Beulich [this message]
2005-07-04 8:11 ` [PATCH] x86_64 trap table fixup Keir Fraser
-- strict thread matches above, loose matches on Subject: below --
2005-07-04 5:59 Nakajima, Jun
2005-07-04 4:27 Chris Wright
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=s2c894e1.027@lucius.provo.novell.com \
--to=jbeulich@novell.com \
--cc=chrisw@osdl.org \
--cc=xen-devel@lists.xensource.com \
/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.