* [PATCH] x86_64 trap table fixup
@ 2005-07-04 4:27 Chris Wright
0 siblings, 0 replies; 4+ messages in thread
From: Chris Wright @ 2005-07-04 4:27 UTC (permalink / raw)
To: Keir.Fraser; +Cc: xen-devel
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)
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [PATCH] x86_64 trap table fixup
@ 2005-07-04 5:59 Nakajima, Jun
0 siblings, 0 replies; 4+ messages in thread
From: Nakajima, Jun @ 2005-07-04 5:59 UTC (permalink / raw)
To: Chris Wright, Keir.Fraser; +Cc: xen-devel
Chris Wright wrote:
> 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>
Good to know that the breakage was this minor ;-). It worked for me.
Thanks,
Jun
---
Intel Open Source Technology Center
> ---
>
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86_64 trap table fixup
@ 2005-07-04 7:46 Jan Beulich
2005-07-04 8:11 ` Keir Fraser
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2005-07-04 7:46 UTC (permalink / raw)
To: chrisw; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86_64 trap table fixup
2005-07-04 7:46 [PATCH] x86_64 trap table fixup Jan Beulich
@ 2005-07-04 8:11 ` Keir Fraser
0 siblings, 0 replies; 4+ messages in thread
From: Keir Fraser @ 2005-07-04 8:11 UTC (permalink / raw)
To: Jan Beulich; +Cc: chrisw, xen-devel
On 4 Jul 2005, at 08:46, Jan Beulich wrote:
> 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)?
The guest OS is allowed to set the DPL as it wants -- in the case of
xenlinux we want to retain maximum compatibility with native Linux.
Other paravirtualised OSes can set the DPL to zero if they wish. In the
case of Windows, that will only run on VT/SVM hardware anyway, and that
deals with handling the guest's IDT pretty much automatically, so these
paravirtual interfaces aren;t used at all.
-- Keir
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-07-04 8:11 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-04 7:46 [PATCH] x86_64 trap table fixup Jan Beulich
2005-07-04 8:11 ` 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
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.