x86_64: Fix double fault stack setup.
Dont forget to push error_code and entry_vector onto the stack for a double
fault. If it is missed, the register information printed looks like
(XEN) CPU: 0
(XEN) RIP: 0246:[<000000000000e008>] ???
(XEN) RFLAGS: ffff82c480287eb8
(XEN) rax: 0000000000000282 rbx: ffff82c480242dd0 rcx: 0000000000000282
(XEN) rdx: 0000000000000000 rsi: 0000000000000282 rdi: 0000000000000031
(XEN) rbp: 0000000000000031 rsp: 0000000000000000 r8: ffff83007ee52488
(XEN) r9: ffff83007ee61088 r10: 0000000000000007 r11: ffff82c480116460
(XEN) r12: 0000000000000000 r13: ffff82c4802c37e0 r14: 00026501a9ced0b8
(XEN) r15: ffff82c4802c37c0 cs: 0000000000000246 ss: 0000000000000000
which incorrectly displays cs, rip, rflags and rsp; the useful pieces of
information when trying to identify the cause of a double fault.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
diff -r 69c3ae25bb1d xen/arch/x86/x86_64/entry.S
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -595,6 +595,8 @@ ENTRY(spurious_interrupt_bug)
jmp handle_exception
ENTRY(double_fault)
+ pushq $0
+ movl $TRAP_double_fault,4(%rsp)
SAVE_ALL
movq %rsp,%rdi
call do_double_fault
--
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 24.05.12 at 16:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > x86_64: Fix double fault stack setup. > > Dont forget to push error_code and entry_vector onto the stack for a double > fault. If it is missed, the register information printed looks like > > (XEN) CPU: 0 > (XEN) RIP: 0246:[<000000000000e008>] ??? > (XEN) RFLAGS: ffff82c480287eb8 > (XEN) rax: 0000000000000282 rbx: ffff82c480242dd0 rcx: 0000000000000282 > (XEN) rdx: 0000000000000000 rsi: 0000000000000282 rdi: 0000000000000031 > (XEN) rbp: 0000000000000031 rsp: 0000000000000000 r8: ffff83007ee52488 > (XEN) r9: ffff83007ee61088 r10: 0000000000000007 r11: ffff82c480116460 > (XEN) r12: 0000000000000000 r13: ffff82c4802c37e0 r14: 00026501a9ced0b8 > (XEN) r15: ffff82c4802c37c0 cs: 0000000000000246 ss: 0000000000000000 > > which incorrectly displays cs, rip, rflags and rsp; the useful pieces of > information when trying to identify the cause of a double fault.Is this from an actual double fault, or from one of your INT 08 attempts to simulate one? An actual exception pushes an error code, so I''m afraid the change below is wrong. Jan> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > > diff -r 69c3ae25bb1d xen/arch/x86/x86_64/entry.S > --- a/xen/arch/x86/x86_64/entry.S > +++ b/xen/arch/x86/x86_64/entry.S > @@ -595,6 +595,8 @@ ENTRY(spurious_interrupt_bug) > jmp handle_exception > > ENTRY(double_fault) > + pushq $0 > + movl $TRAP_double_fault,4(%rsp) > SAVE_ALL > movq %rsp,%rdi > call do_double_fault > > -- > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer > T: +44 (0)1223 225 900, http://www.citrix.com
On 24/05/12 16:14, Jan Beulich wrote:>>>> On 24.05.12 at 16:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> x86_64: Fix double fault stack setup. >> >> Dont forget to push error_code and entry_vector onto the stack for a double >> fault. If it is missed, the register information printed looks like >> >> (XEN) CPU: 0 >> (XEN) RIP: 0246:[<000000000000e008>] ??? >> (XEN) RFLAGS: ffff82c480287eb8 >> (XEN) rax: 0000000000000282 rbx: ffff82c480242dd0 rcx: 0000000000000282 >> (XEN) rdx: 0000000000000000 rsi: 0000000000000282 rdi: 0000000000000031 >> (XEN) rbp: 0000000000000031 rsp: 0000000000000000 r8: ffff83007ee52488 >> (XEN) r9: ffff83007ee61088 r10: 0000000000000007 r11: ffff82c480116460 >> (XEN) r12: 0000000000000000 r13: ffff82c4802c37e0 r14: 00026501a9ced0b8 >> (XEN) r15: ffff82c4802c37c0 cs: 0000000000000246 ss: 0000000000000000 >> >> which incorrectly displays cs, rip, rflags and rsp; the useful pieces of >> information when trying to identify the cause of a double fault. > Is this from an actual double fault, or from one of your INT 08 > attempts to simulate one? An actual exception pushes an error > code, so I''m afraid the change below is wrong. > > JanAh yes - how silly of me. I misread the manual when checking that fact, but this was an INT 08 experiment. I really should have checked with a ud2 as well. That is a bit awkward. Do we actually care about this error from an INT 08? I suppose we could check under rip for 0xcd 0x08, but then the same argument would apply to all other exceptions which may push an error onto the stack. Do we care however that entry_vector is not being set correctly? I cant see anything on the current codepath which uses it, but it doesn''t preclude someone adding code in the future. ~Andrew> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> >> >> diff -r 69c3ae25bb1d xen/arch/x86/x86_64/entry.S >> --- a/xen/arch/x86/x86_64/entry.S >> +++ b/xen/arch/x86/x86_64/entry.S >> @@ -595,6 +595,8 @@ ENTRY(spurious_interrupt_bug) >> jmp handle_exception >> >> ENTRY(double_fault) >> + pushq $0 >> + movl $TRAP_double_fault,4(%rsp) >> SAVE_ALL >> movq %rsp,%rdi >> call do_double_fault >> >> -- >> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer >> T: +44 (0)1223 225 900, http://www.citrix.com > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel-- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
>>> On 24.05.12 at 17:28, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > Do we actually care about this error from an INT 08?Definitely not - the hypervisor doesn''t (except in your debugging) ever use INT nn, and nothing else can access those gates.> I suppose we could check under rip for 0xcd 0x08,That''s (from my pov) an absolute no-go for the double fault handler, even if the above didn''t hold. Jan
On 24/05/12 16:46, Jan Beulich wrote:>>>> On 24.05.12 at 17:28, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> Do we actually care about this error from an INT 08? > Definitely not - the hypervisor doesn''t (except in your debugging) > ever use INT nn, and nothing else can access those gates.Ok - I will avoid debugging in this fashion in the future.> >> I suppose we could check under rip for 0xcd 0x08, > That''s (from my pov) an absolute no-go for the double fault > handler, even if the above didn''t hold. > > JanYes. After further considering, this adds an extra fault in that the #DF handler would not successfully return, which was being hidden in my tests by the crash kernel. What about the entry vector? It would be safe to do in the case of a real #DF, and wont really break the int08 case much more than it already is. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
On 24/05/2012 16:28, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:> Ah yes - how silly of me. I misread the manual when checking that fact, > but this was an INT 08 experiment. I really should have checked with a > ud2 as well. > > That is a bit awkward. > > Do we actually care about this error from an INT 08? I suppose we could > check under rip for 0xcd 0x08, but then the same argument would apply to > all other exceptions which may push an error onto the stack. > > Do we care however that entry_vector is not being set correctly? I cant > see anything on the current codepath which uses it, but it doesn''t > preclude someone adding code in the future.It would be a simple one-line patch and make that entry point consistent with all other exception-handling entry points. So I''m in favour of it. -- Keir
On 24/05/12 19:04, Keir Fraser wrote:> On 24/05/2012 16:28, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote: > >> Ah yes - how silly of me. I misread the manual when checking that fact, >> but this was an INT 08 experiment. I really should have checked with a >> ud2 as well. >> >> That is a bit awkward. >> >> Do we actually care about this error from an INT 08? I suppose we could >> check under rip for 0xcd 0x08, but then the same argument would apply to >> all other exceptions which may push an error onto the stack. >> >> Do we care however that entry_vector is not being set correctly? I cant >> see anything on the current codepath which uses it, but it doesn''t >> preclude someone adding code in the future. > It would be a simple one-line patch and make that entry point consistent > with all other exception-handling entry points. So I''m in favour of it. > > -- KeirOk - attached. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 24.05.12 at 18:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > What about the entry vector? It would be safe to do in the case of a > real #DF, and wont really break the int08 case much more than it already is.That could be done for completeness, perhaps also in early_page_fault. Jan
On 25/05/2012 11:35, "Jan Beulich" <JBeulich@suse.com> wrote:>>>> On 24.05.12 at 18:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> What about the entry vector? It would be safe to do in the case of a >> real #DF, and wont really break the int08 case much more than it already is. > > That could be done for completeness, perhaps also in > early_page_fault.Because it''s obviously a special-case boot-time handler, I''m not so bothered. But I''m happy for you to make the change, if you like. -- Keir> Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel