[Xen-ia64-devel] Re: [Xen-devel] [Patch] [RFC] avoid debugger_trap when we don't expect
This doesn't need to be fixed on x86 -- the int3 handler will return silently if the debugger is not configured. It would be nice if the ia64 handler would do the same. If that is not possible then change only ia64 code and if you need to be able to probe gdbstub configuration then add a public function to do that rather than grope at internal state. The same goes for powerpc, *if* it is broken in the first place. -- Keir On 30/1/08 05:03, Akio Takebe [EMAIL PROTECTED] wrote: Hi, This patch avoid debugger_trap when we don't setup a debugger. kexec_crash() is called after debugger_trap_immediate(). Because we want to use the safe path at kexecing, we should avoid the debugger path. And the trap is a needless work. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe ___ Xen-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [Patch] [RFC] avoid debugger_trap when we don't expect
Hi, Keir This doesn't need to be fixed on x86 -- the int3 handler will return silently if the debugger is not configured. It would be nice if the ia64 handler would do the same. If that is not possible then change only ia64 code and if you need to be able to probe gdbstub configuration then add a public function to do that rather than grope at internal state. The same goes for powerpc, *if* it is broken in the first place. I know the int3 hanlder return well on x86 if it is not configured. But the route may be not safe. The debugger_trap is called after hypervisor panic and dom0 panic. So I want to avoid the needless route for kexec/kdump. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [Patch] [RFC] avoid debugger_trap when we don't expect
On 30/1/08 08:48, Akio Takebe [EMAIL PROTECTED] wrote: This doesn't need to be fixed on x86 -- the int3 handler will return silently if the debugger is not configured. It would be nice if the ia64 handler would do the same. If that is not possible then change only ia64 code and if you need to be able to probe gdbstub configuration then add a public function to do that rather than grope at internal state. The same goes for powerpc, *if* it is broken in the first place. I know the int3 hanlder return well on x86 if it is not configured. But the route may be not safe. The debugger_trap is called after hypervisor panic and dom0 panic. So I want to avoid the needless route for kexec/kdump. Oh no, then all bets are off. :-) We could be screwed and fail to kexec no matter what we do. -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [Patch] [RFC] avoid debugger_trap when we don't expect
Hi, Keir On 30/1/08 08:48, Akio Takebe [EMAIL PROTECTED] wrote: This doesn't need to be fixed on x86 -- the int3 handler will return silently if the debugger is not configured. It would be nice if the ia64 handler would do the same. If that is not possible then change only ia64 code and if you need to be able to probe gdbstub configuration then add a public function to do that rather than grope at internal state. The same goes for powerpc, *if* it is broken in the first place. I know the int3 hanlder return well on x86 if it is not configured. But the route may be not safe. The debugger_trap is called after hypervisor panic and dom0 panic. So I want to avoid the needless route for kexec/kdump. Oh no, then all bets are off. :-) We could be screwed and fail to kexec no matter what we do. OK. I just suggested a safer way than current code. Recently we found a bug around the trap handler on ia64, so I worry about such a thing. I still want to avoid the needless code on ia64. so I'll talk in xen-ia64 ML. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
