Akio Takebe
2008-Jan-30 05:03 UTC
[XenPPC] [Patch] [RFC] avoid debugger_trap when we don''t expect
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 <takebe_akio@jp.fujitsu.com> Best Regards, Akio Takebe _______________________________________________ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Keir Fraser
2008-Jan-30 08:27 UTC
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" <takebe_akio@jp.fujitsu.com> 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 <takebe_akio@jp.fujitsu.com> > > Best Regards, > > Akio Takebe > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Akio Takebe
2008-Jan-30 08:48 UTC
[XenPPC] 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-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Keir Fraser
2008-Jan-30 09:26 UTC
Re: [Xen-devel] [Patch] [RFC] avoid debugger_trap when we don''t expect
On 30/1/08 08:48, "Akio Takebe" <takebe_akio@jp.fujitsu.com> 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-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Akio Takebe
2008-Jan-31 00:56 UTC
[XenPPC] Re: [Xen-devel] [Patch] [RFC] avoid debugger_trap when we don''t expect
Hi, Keir>On 30/1/08 08:48, "Akio Takebe" <takebe_akio@jp.fujitsu.com> 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-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel