RE: [PATCH] make domu_debug run-time option + fix int3handling for MP

RE: [PATCH] make domu_debug run-time option + fix int3handling for MP

[Ian Pratt]

> On Mon, May 16, 2005 at 03:08:24PM -0700, Kip Macy wrote:
> > "domu_debug" was mutually exclusive with crash_debug, which doesn't 
> > make sense to me. The other stub already had a #if 0 as a 
> > pre-processor guard around it. So the end effect with the patch is 
> > that domu_debug would be on by default and cdb could be enabled at 
> > compile-time. As I recall, there is no working 
> functionality that this changes.  I'll go back and look and 
> recant if I am in error.
> 
> Unless I misread the patch (didn't apply it), you'd end up 
> with unconditional definitions of debugger_trap_fatal and 
> debugger_trap_immediate?
> I usually just toggle the #elif 0 to enable the kdb stubs, I 
> don't see how that would work now, without having to do more changes?

Do we ever want to enter cdb or kdb for any domain other than dom0? I
can't think why you'd want to, as there's a much nicer debug environment
available for domU's.

Ian

Re: [PATCH] make domu_debug run-time option + fix int3handling for MP

[Christian Limpach]

On 5/16/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> > On Mon, May 16, 2005 at 03:08:24PM -0700, Kip Macy wrote:
> > > "domu_debug" was mutually exclusive with crash_debug, which doesn't
> > > make sense to me. The other stub already had a #if 0 as a
> > > pre-processor guard around it. So the end effect with the patch is
> > > that domu_debug would be on by default and cdb could be enabled at
> > > compile-time. As I recall, there is no working
> > functionality that this changes.  I'll go back and look and
> > recant if I am in error.
> >
> > Unless I misread the patch (didn't apply it), you'd end up
> > with unconditional definitions of debugger_trap_fatal and
> > debugger_trap_immediate?
> > I usually just toggle the #elif 0 to enable the kdb stubs, I
> > don't see how that would work now, without having to do more changes?
> 
> Do we ever want to enter cdb or kdb for any domain other than dom0? I
> can't think why you'd want to, as there's a much nicer debug environment
> available for domU's.

debugger_trap_fatal and debugger_trap_immediate are only used in code
paths which cause a Xen reboot and the nicer debug environment will be
dead by then...

Good point though for making debugger_trap_entry domu_debug only,
might even be reasonable to rename it...

    christian