Hi, Apologies if this is not the appropriate list, but I thought I would have better luck here than on xen-users. I''m a CS graduate student hacking on the xen-blkback driver and would like to be able to debug it using gdb over serial. I have spent a great deal of time on this with no success (more details can be found at http://bit.ly/KMEF6o (Stack Overflow)). It eventually occurred to me that it might not even be possible to do what I''m trying to do if Xen intercepts interrupts from the serial port and tries to direct them to dom0 through some unexpected channel. Then, after I''ve done `echo g > /proc/sysrq_trigger`, the kernel debugger might not see the interrupt. Can anyone confirm or disconfirm this? What is the usual procedure for debugging the Dom0 kernel? Thank you, James Paton
On Wed, 2012-06-06 at 00:24 +0100, James Paton wrote:> Hi, > > Apologies if this is not the appropriate list, but I thought I would > have better luck here than on xen-users. > > I''m a CS graduate student hacking on the xen-blkback driver and would > like to be able to debug it using gdb over serial. I have spent a great > deal of time on this with no success (more details can be found at > http://bit.ly/KMEF6o (Stack Overflow)). > > It eventually occurred to me that it might not even be possible to do > what I''m trying to do if Xen intercepts interrupts from the serial port > and tries to direct them to dom0 through some unexpected channel. Then, > after I''ve done `echo g > /proc/sysrq_trigger`, the kernel debugger > might not see the interrupt. Can anyone confirm or disconfirm this?It''s not something I''ve ever tried but I expect that if you avoid console=com1 (or com*) on your hypervisor command line then the com port should be available for dom0 just like on native. Alternatively you could perhaps separate the two by using com1 for Xen and com2/ttyS1 for dom0/kdb etc. I''ve no idea if kdb would be expected to work over hvc*. I suspect you''d be treading fresh ground with that one... I''d also start by taking virtual box out of the equation on the host side. Start by using a MacOS terminal emulator and checking that you can see the dom0 console messages and login via a getty running on ttyS0 before trying to hook up gdb.> What is the usual procedure for debugging the Dom0 kernel?Printk ;-) Ian.
On Wed, Jun 06, 2012 at 10:13:44AM +0100, Ian Campbell wrote:> On Wed, 2012-06-06 at 00:24 +0100, James Paton wrote: > > Hi, > > > > Apologies if this is not the appropriate list, but I thought I would > > have better luck here than on xen-users. > > > > I''m a CS graduate student hacking on the xen-blkback driver and would > > like to be able to debug it using gdb over serial. I have spent a great > > deal of time on this with no success (more details can be found at > > http://bit.ly/KMEF6o (Stack Overflow)). > > > > It eventually occurred to me that it might not even be possible to do > > what I''m trying to do if Xen intercepts interrupts from the serial port > > and tries to direct them to dom0 through some unexpected channel. Then, > > after I''ve done `echo g > /proc/sysrq_trigger`, the kernel debugger > > might not see the interrupt. Can anyone confirm or disconfirm this? > > It''s not something I''ve ever tried but I expect that if you avoid > console=com1 (or com*) on your hypervisor command line then the com port > should be available for dom0 just like on native. > > Alternatively you could perhaps separate the two by using com1 for Xen > and com2/ttyS1 for dom0/kdb etc. > > I''ve no idea if kdb would be expected to work over hvc*. I suspect you''d > be treading fresh ground with that one... > > I''d also start by taking virtual box out of the equation on the host > side. Start by using a MacOS terminal emulator and checking that you can > see the dom0 console messages and login via a getty running on ttyS0 > before trying to hook up gdb. > > > What is the usual procedure for debugging the Dom0 kernel? > > Printk ;-):-)))))) any variation of this is the best debugging tool for every piece of software... ... but another option is plain QEMU. Just download it (http://wiki.qemu.org/Main_Page), install minimal set of software relevant for your needs and look for following options: - -serial - is a must; I use following combination: ... -serial telnet:127.0.0.1:10232,server ... you could access it by: telnet 127.0.0.1 10232 - -gdb - remote access for GDB; I use following combination: ... -gdb tcp:127.0.0.1:1234 ... you could connect from GDB using following command: target remote :1234 do not forget to compile your software with symbols - -monitor - useful if you need check something in memory (especially if you know only physical address - xp command; but also look for others; I am sure that some could be useful for you); I use following combination: ... -monitor telnet:127.0.0.1:1233,server,nowait ... you could access it by: telnet 127.0.0.1 1233 quit from monitor: Ctrl-] and then quit command - -debugcon - I have not tested it yet but it looks very promising; usage is very similar to serial option; however, you do not need to do any hardware initialization (serial ports require it); just send anything to port 0xe9 (simple outb) Daniel
Thanks everyone for your help. I tried the suggestion of leaving ttyS1 out of the Xen boot options and using that. I confirmed that I can echo things back and forth through that connection from the host OS. I compiled a custom version of gdb to target x86_64-linux-gnu so I could do remote debugging from the host. No luck. I also tried setting console=ttyS1 for the dom0 kernel -- same outcome. Next, using exactly the same settings, I booted the dom0 kernel bare (no Xen this time) and tried the same thing. This time, it worked. I can connect the debugger and it breaks as expected. So I''m thinking debugging while running Xen over serial is a dead end, unless I figure out a way to do it over hvc. I think for now I''ll just use printk. -- Jim
What kernel version?
Below is a patch against 3.2.y that allows for debug using kdb over hvc
Some bits of this were recently upstreamed as part of some perf-tools
work in pvops...but the debug_core.c, and hvc_console.c didn''t make
it.
With this patch, you can add the kernel parameter
kgdboc=hvc0
Alternately, at runtime by doing the following:
echo hvc0 > /sys/module/kgdboc/parameters/kgdboc
To break into the debugger, you need to press the magic SysRq key
sequence "Alt+SysRq+g"
While you are in the debugger, you are in "polling" console mode. As
such, there seems to be a limitation on how fast you can type
commands. I found that when I typed two letters too fast, it just
printed the help text again.
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d5e0e0a..88815a1 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -65,6 +65,7 @@
#include "xen-ops.h"
#include "mmu.h"
+#include "smp.h"
#include "multicalls.h"
EXPORT_SYMBOL_GPL(hypercall_page);
@@ -768,6 +769,12 @@ static void set_xen_basic_apic_ops(void)
apic->icr_write = xen_apic_icr_write;
apic->wait_icr_idle = xen_apic_wait_icr_idle;
apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
+
+ apic->send_IPI_allbutself = xen_send_IPI_allbutself;
+ apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
+ apic->send_IPI_mask = xen_send_IPI_mask;
+ apic->send_IPI_all = xen_send_IPI_all;
+ apic->send_IPI_self = xen_send_IPI_self;
}
#endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3061244..d8928a1 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -436,8 +436,8 @@ static void xen_smp_send_reschedule(int cpu)
xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
}
-static void xen_send_IPI_mask(const struct cpumask *mask,
- enum ipi_vector vector)
+void xen_send_IPI_mask(const struct cpumask *mask,
+ int vector)
{
unsigned cpu;
@@ -466,6 +466,39 @@ static void xen_smp_send_call_function_single_ipi(int cpu)
XEN_CALL_FUNCTION_SINGLE_VECTOR);
}
+void xen_send_IPI_all(int vector)
+{
+ xen_send_IPI_mask(cpu_online_mask, vector);
+}
+
+void xen_send_IPI_self(int vector)
+{
+ xen_send_IPI_one(smp_processor_id(), vector);
+}
+
+void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+ int vector)
+{
+ unsigned cpu;
+ unsigned int this_cpu = smp_processor_id();
+
+ if (!(num_online_cpus() > 1))
+ return;
+
+ for_each_cpu_and(cpu, mask, cpu_online_mask) {
+ if (this_cpu == cpu)
+ continue;
+
+ xen_smp_send_call_function_single_ipi(cpu);
+ }
+}
+
+void xen_send_IPI_allbutself(int vector)
+{
+ xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
+}
+
+
static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
{
irq_enter();
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
new file mode 100644
index 0000000..8981a76
--- /dev/null
+++ b/arch/x86/xen/smp.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_SMP_H
+
+extern void xen_send_IPI_mask(const struct cpumask *mask,
+ int vector);
+extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+ int vector);
+extern void xen_send_IPI_allbutself(int vector);
+extern void physflat_send_IPI_allbutself(int vector);
+extern void xen_send_IPI_all(int vector);
+extern void xen_send_IPI_self(int vector);
+
+#endif
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 58ca7ce..4addc80 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -754,13 +754,10 @@ int hvc_poll_init(struct tty_driver *driver, int
line, char *options)
static int hvc_poll_get_char(struct tty_driver *driver, int line)
{
- struct tty_struct *tty = driver->ttys[0];
- struct hvc_struct *hp = tty->driver_data;
int n;
char ch;
- n = hp->ops->get_chars(hp->vtermno, &ch, 1);
-
+ n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
if (n == 0)
return NO_POLL_CHAR;
@@ -769,12 +766,10 @@ static int hvc_poll_get_char(struct tty_driver
*driver, int line)
static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
{
- struct tty_struct *tty = driver->ttys[0];
- struct hvc_struct *hp = tty->driver_data;
int n;
do {
- n = hp->ops->put_chars(hp->vtermno, &ch, 1);
+ n = cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
} while (n <= 0);
}
#endif
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index cefd4a1..df904a5 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -581,12 +581,14 @@ return_normal:
kgdb_roundup_cpus(flags);
#endif
+#ifndef CONFIG_XEN
/*
* Wait for the other CPUs to be notified and be waiting for us:
*/
while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
atomic_read(&slaves_in_kgdb)) != online_cpus)
cpu_relax();
+#endif
/*
* At this point the primary processor is completely
On Wed, Jun 6, 2012 at 3:55 PM, James Paton <paton@cs.wisc.edu>
wrote:>
> Thanks everyone for your help.
>
> I tried the suggestion of leaving ttyS1 out of the Xen boot options and
using that. I confirmed that I can echo things back and forth through that
connection from the host OS. I compiled a custom version of gdb to target
x86_64-linux-gnu so I could do remote debugging from the host. No luck. I also
tried setting console=ttyS1 for the dom0 kernel -- same outcome.
>
> Next, using exactly the same settings, I booted the dom0 kernel bare (no
Xen this time) and tried the same thing. This time, it worked. I can connect the
debugger and it breaks as expected. So I''m thinking debugging while
running Xen over serial is a dead end, unless I figure out a way to do it over
hvc. I think for now I''ll just use printk.
>
> -- Jim
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
On Wed, 6 Jun 2012 10:13:44 +0100 Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Wed, 2012-06-06 at 00:24 +0100, James Paton wrote: > > Hi, > > > > Apologies if this is not the appropriate list, but I thought I > > would have better luck here than on xen-users. > > > > I''m a CS graduate student hacking on the xen-blkback driver and > > would like to be able to debug it using gdb over serial. I have > > spent a great deal of time on this with no success (more details > > can be found at http://bit.ly/KMEF6o (Stack Overflow)). > > > > It eventually occurred to me that it might not even be possible to > > do what I''m trying to do if Xen intercepts interrupts from the > > serial port and tries to direct them to dom0 through some > > unexpected channel. Then, after I''ve done `echo g > > > /proc/sysrq_trigger`, the kernel debugger might not see the > > > interrupt. Can anyone confirm or disconfirm this? > > It''s not something I''ve ever tried but I expect that if you avoid > console=com1 (or com*) on your hypervisor command line then the com > port should be available for dom0 just like on native. > > Alternatively you could perhaps separate the two by using com1 for Xen > and com2/ttyS1 for dom0/kdb etc. > > I''ve no idea if kdb would be expected to work over hvc*. I suspect > you''d be treading fresh ground with that one... > > I''d also start by taking virtual box out of the equation on the host > side. Start by using a MacOS terminal emulator and checking that you > can see the dom0 console messages and login via a getty running on > ttyS0 before trying to hook up gdb. > > > What is the usual procedure for debugging the Dom0 kernel? > > Printk ;-) > > Ian.I wrote up a debugger for xen, also (mis)named kdb. It halts the system, lets you poke memory, data structs, set breakpoints, etc. To use it, you must have prior experience of a kernel debugger. I am attaching patch build for changeset 25287 in unstable tree, if you wanna try it. Start with kdb/README. Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Wed, Jun 06, 2012 at 04:54:56PM -0400, Ben Guthro wrote:> What kernel version? > > Below is a patch against 3.2.y that allows for debug using kdb over hvc > > Some bits of this were recently upstreamed as part of some perf-tools > work in pvops...but the debug_core.c, and hvc_console.c didn''t make > it.I would be interested in seeing them against v3.5-rc1..> > With this patch, you can add the kernel parameter > kgdboc=hvc0 > > Alternately, at runtime by doing the following: > echo hvc0 > /sys/module/kgdboc/parameters/kgdboc > > To break into the debugger, you need to press the magic SysRq key > sequence "Alt+SysRq+g" > > While you are in the debugger, you are in "polling" console mode. As > such, there seems to be a limitation on how fast you can type > commands. I found that when I typed two letters too fast, it just > printed the help text again. > > > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index d5e0e0a..88815a1 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -65,6 +65,7 @@ > > #include "xen-ops.h" > #include "mmu.h" > +#include "smp.h" > #include "multicalls.h" > > EXPORT_SYMBOL_GPL(hypercall_page); > @@ -768,6 +769,12 @@ static void set_xen_basic_apic_ops(void) > apic->icr_write = xen_apic_icr_write; > apic->wait_icr_idle = xen_apic_wait_icr_idle; > apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle; > + > + apic->send_IPI_allbutself = xen_send_IPI_allbutself; > + apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself; > + apic->send_IPI_mask = xen_send_IPI_mask; > + apic->send_IPI_all = xen_send_IPI_all; > + apic->send_IPI_self = xen_send_IPI_self; > } > > #endif > diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c > index 3061244..d8928a1 100644 > --- a/arch/x86/xen/smp.c > +++ b/arch/x86/xen/smp.c > @@ -436,8 +436,8 @@ static void xen_smp_send_reschedule(int cpu) > xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR); > } > > -static void xen_send_IPI_mask(const struct cpumask *mask, > - enum ipi_vector vector) > +void xen_send_IPI_mask(const struct cpumask *mask, > + int vector) > { > unsigned cpu; > > @@ -466,6 +466,39 @@ static void xen_smp_send_call_function_single_ipi(int cpu) > XEN_CALL_FUNCTION_SINGLE_VECTOR); > } > > +void xen_send_IPI_all(int vector) > +{ > + xen_send_IPI_mask(cpu_online_mask, vector); > +} > + > +void xen_send_IPI_self(int vector) > +{ > + xen_send_IPI_one(smp_processor_id(), vector); > +} > + > +void xen_send_IPI_mask_allbutself(const struct cpumask *mask, > + int vector) > +{ > + unsigned cpu; > + unsigned int this_cpu = smp_processor_id(); > + > + if (!(num_online_cpus() > 1)) > + return; > + > + for_each_cpu_and(cpu, mask, cpu_online_mask) { > + if (this_cpu == cpu) > + continue; > + > + xen_smp_send_call_function_single_ipi(cpu); > + } > +} > + > +void xen_send_IPI_allbutself(int vector) > +{ > + xen_send_IPI_mask_allbutself(cpu_online_mask, vector); > +} > + > + > static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id) > { > irq_enter(); > diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h > new file mode 100644 > index 0000000..8981a76 > --- /dev/null > +++ b/arch/x86/xen/smp.h > @@ -0,0 +1,12 @@ > +#ifndef _XEN_SMP_H > + > +extern void xen_send_IPI_mask(const struct cpumask *mask, > + int vector); > +extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask, > + int vector); > +extern void xen_send_IPI_allbutself(int vector); > +extern void physflat_send_IPI_allbutself(int vector); > +extern void xen_send_IPI_all(int vector); > +extern void xen_send_IPI_self(int vector); > + > +#endif > diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c > index 58ca7ce..4addc80 100644 > --- a/drivers/tty/hvc/hvc_console.c > +++ b/drivers/tty/hvc/hvc_console.c > @@ -754,13 +754,10 @@ int hvc_poll_init(struct tty_driver *driver, int > line, char *options) > > static int hvc_poll_get_char(struct tty_driver *driver, int line) > { > - struct tty_struct *tty = driver->ttys[0]; > - struct hvc_struct *hp = tty->driver_data; > int n; > char ch; > > - n = hp->ops->get_chars(hp->vtermno, &ch, 1); > - > + n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1); > if (n == 0) > return NO_POLL_CHAR; > > @@ -769,12 +766,10 @@ static int hvc_poll_get_char(struct tty_driver > *driver, int line) > > static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch) > { > - struct tty_struct *tty = driver->ttys[0]; > - struct hvc_struct *hp = tty->driver_data; > int n; > > do { > - n = hp->ops->put_chars(hp->vtermno, &ch, 1); > + n = cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1); > } while (n <= 0); > } > #endif > diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c > index cefd4a1..df904a5 100644 > --- a/kernel/debug/debug_core.c > +++ b/kernel/debug/debug_core.c > @@ -581,12 +581,14 @@ return_normal: > kgdb_roundup_cpus(flags); > #endif > > +#ifndef CONFIG_XEN > /* > * Wait for the other CPUs to be notified and be waiting for us: > */ > while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) + > atomic_read(&slaves_in_kgdb)) != online_cpus) > cpu_relax(); > +#endif > > /* > * At this point the primary processor is completely > > > > > > On Wed, Jun 6, 2012 at 3:55 PM, James Paton <paton@cs.wisc.edu> wrote: > > > > Thanks everyone for your help. > > > > I tried the suggestion of leaving ttyS1 out of the Xen boot options and using that. I confirmed that I can echo things back and forth through that connection from the host OS. I compiled a custom version of gdb to target x86_64-linux-gnu so I could do remote debugging from the host. No luck. I also tried setting console=ttyS1 for the dom0 kernel -- same outcome. > > > > Next, using exactly the same settings, I booted the dom0 kernel bare (no Xen this time) and tried the same thing. This time, it worked. I can connect the debugger and it breaks as expected. So I''m thinking debugging while running Xen over serial is a dead end, unless I figure out a way to do it over hvc. I think for now I''ll just use printk. > > > > -- Jim > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Thank you! I am using 3.3.6, but by manually applying your patch, I got it to work. I''ve attached a patch for 3.3.6 in case anyone would find it useful. -- Jim -- Jim On Jun 6, 2012, at 3:54 PM, Ben Guthro wrote:> What kernel version? > > Below is a patch against 3.2.y that allows for debug using kdb over hvc > > Some bits of this were recently upstreamed as part of some perf-tools > work in pvops...but the debug_core.c, and hvc_console.c didn''t make > it. > > With this patch, you can add the kernel parameter > kgdboc=hvc0 > > Alternately, at runtime by doing the following: > echo hvc0 > /sys/module/kgdboc/parameters/kgdboc > > To break into the debugger, you need to press the magic SysRq key > sequence "Alt+SysRq+g" > > While you are in the debugger, you are in "polling" console mode. As > such, there seems to be a limitation on how fast you can type > commands. I found that when I typed two letters too fast, it just > printed the help text again. > > > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index d5e0e0a..88815a1 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -65,6 +65,7 @@ > > #include "xen-ops.h" > #include "mmu.h" > +#include "smp.h" > #include "multicalls.h" > > EXPORT_SYMBOL_GPL(hypercall_page); > @@ -768,6 +769,12 @@ static void set_xen_basic_apic_ops(void) > apic->icr_write = xen_apic_icr_write; > apic->wait_icr_idle = xen_apic_wait_icr_idle; > apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle; > + > + apic->send_IPI_allbutself = xen_send_IPI_allbutself; > + apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself; > + apic->send_IPI_mask = xen_send_IPI_mask; > + apic->send_IPI_all = xen_send_IPI_all; > + apic->send_IPI_self = xen_send_IPI_self; > } > > #endif > diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c > index 3061244..d8928a1 100644 > --- a/arch/x86/xen/smp.c > +++ b/arch/x86/xen/smp.c > @@ -436,8 +436,8 @@ static void xen_smp_send_reschedule(int cpu) > xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR); > } > > -static void xen_send_IPI_mask(const struct cpumask *mask, > - enum ipi_vector vector) > +void xen_send_IPI_mask(const struct cpumask *mask, > + int vector) > { > unsigned cpu; > > @@ -466,6 +466,39 @@ static void xen_smp_send_call_function_single_ipi(int cpu) > XEN_CALL_FUNCTION_SINGLE_VECTOR); > } > > +void xen_send_IPI_all(int vector) > +{ > + xen_send_IPI_mask(cpu_online_mask, vector); > +} > + > +void xen_send_IPI_self(int vector) > +{ > + xen_send_IPI_one(smp_processor_id(), vector); > +} > + > +void xen_send_IPI_mask_allbutself(const struct cpumask *mask, > + int vector) > +{ > + unsigned cpu; > + unsigned int this_cpu = smp_processor_id(); > + > + if (!(num_online_cpus() > 1)) > + return; > + > + for_each_cpu_and(cpu, mask, cpu_online_mask) { > + if (this_cpu == cpu) > + continue; > + > + xen_smp_send_call_function_single_ipi(cpu); > + } > +} > + > +void xen_send_IPI_allbutself(int vector) > +{ > + xen_send_IPI_mask_allbutself(cpu_online_mask, vector); > +} > + > + > static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id) > { > irq_enter(); > diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h > new file mode 100644 > index 0000000..8981a76 > --- /dev/null > +++ b/arch/x86/xen/smp.h > @@ -0,0 +1,12 @@ > +#ifndef _XEN_SMP_H > + > +extern void xen_send_IPI_mask(const struct cpumask *mask, > + int vector); > +extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask, > + int vector); > +extern void xen_send_IPI_allbutself(int vector); > +extern void physflat_send_IPI_allbutself(int vector); > +extern void xen_send_IPI_all(int vector); > +extern void xen_send_IPI_self(int vector); > + > +#endif > diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c > index 58ca7ce..4addc80 100644 > --- a/drivers/tty/hvc/hvc_console.c > +++ b/drivers/tty/hvc/hvc_console.c > @@ -754,13 +754,10 @@ int hvc_poll_init(struct tty_driver *driver, int > line, char *options) > > static int hvc_poll_get_char(struct tty_driver *driver, int line) > { > - struct tty_struct *tty = driver->ttys[0]; > - struct hvc_struct *hp = tty->driver_data; > int n; > char ch; > > - n = hp->ops->get_chars(hp->vtermno, &ch, 1); > - > + n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1); > if (n == 0) > return NO_POLL_CHAR; > > @@ -769,12 +766,10 @@ static int hvc_poll_get_char(struct tty_driver > *driver, int line) > > static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch) > { > - struct tty_struct *tty = driver->ttys[0]; > - struct hvc_struct *hp = tty->driver_data; > int n; > > do { > - n = hp->ops->put_chars(hp->vtermno, &ch, 1); > + n = cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1); > } while (n <= 0); > } > #endif > diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c > index cefd4a1..df904a5 100644 > --- a/kernel/debug/debug_core.c > +++ b/kernel/debug/debug_core.c > @@ -581,12 +581,14 @@ return_normal: > kgdb_roundup_cpus(flags); > #endif > > +#ifndef CONFIG_XEN > /* > * Wait for the other CPUs to be notified and be waiting for us: > */ > while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) + > atomic_read(&slaves_in_kgdb)) != online_cpus) > cpu_relax(); > +#endif > > /* > * At this point the primary processor is completely > > > > > > On Wed, Jun 6, 2012 at 3:55 PM, James Paton <paton@cs.wisc.edu> wrote: >> >> Thanks everyone for your help. >> >> I tried the suggestion of leaving ttyS1 out of the Xen boot options and using that. I confirmed that I can echo things back and forth through that connection from the host OS. I compiled a custom version of gdb to target x86_64-linux-gnu so I could do remote debugging from the host. No luck. I also tried setting console=ttyS1 for the dom0 kernel -- same outcome. >> >> Next, using exactly the same settings, I booted the dom0 kernel bare (no Xen this time) and tried the same thing. This time, it worked. I can connect the debugger and it breaks as expected. So I''m thinking debugging while running Xen over serial is a dead end, unless I figure out a way to do it over hvc. I think for now I''ll just use printk. >> >> -- Jim >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Wed, 2012-06-06 at 22:17 +0100, Mukesh Rathor wrote:> I wrote up a debugger for xen, also (mis)named kdb. It halts the > system, lets you poke memory, data structs, set breakpoints, etc. > To use it, you must have prior experience of a kernel debugger. I > am attaching patch build for changeset 25287 in unstable tree, if you > wanna try it. Start with kdb/README.I think this is for the hypervisor itself, right? James was asking about debugging the dom0 kernel. I also considered mentioning gdbsx but I think that can only work with domU? Ian.
On Wed, Jun 06, 2012 at 05:07:52PM -0500, James Paton wrote:> Thank you! I am using 3.3.6, but by manually applying your patch, I got it to work. I''ve attached a patch for 3.3.6 in case anyone would find it useful.You sure this is the right patch? It looks to be removing most of the code.
The patch is in reverse of what it should be. On Thu, Jun 7, 2012 at 11:12 AM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Wed, Jun 06, 2012 at 05:07:52PM -0500, James Paton wrote: >> Thank you! I am using 3.3.6, but by manually applying your patch, I got it to work. I''ve attached a patch for 3.3.6 in case anyone would find it useful. > > You sure this is the right patch? It looks to be removing most of the code.
Oops, sorry. This is my first patch ever. Is this one better? On Jun 7, 2012, at 12:04 PM, Ben Guthro wrote:> The patch is in reverse of what it should be. > > On Thu, Jun 7, 2012 at 11:12 AM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: >> On Wed, Jun 06, 2012 at 05:07:52PM -0500, James Paton wrote: >>> Thank you! I am using 3.3.6, but by manually applying your patch, I got it to work. I''ve attached a patch for 3.3.6 in case anyone would find it useful. >> >> You sure this is the right patch? It looks to be removing most of the code._______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, 7 Jun 2012 07:27:26 +0100 Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Wed, 2012-06-06 at 22:17 +0100, Mukesh Rathor wrote: > > I wrote up a debugger for xen, also (mis)named kdb. It halts the > > system, lets you poke memory, data structs, set breakpoints, etc. > > To use it, you must have prior experience of a kernel debugger. I > > am attaching patch build for changeset 25287 in unstable tree, if > > you wanna try it. Start with kdb/README. > > I think this is for the hypervisor itself, right?kdb can be used to set breakpoints, single step, examine memory of the entire system, etc.. so it can be used to debug xen, dom0, domUs.> James was asking about debugging the dom0 kernel. I also considered > mentioning gdbsx but I think that can only work with domU?Right. gdbsx runs on dom0, so can only be used to debug domUs. thanks, Mukesh