I am trying to debug the Xen hypervisor from a second computer over the serial port, but nothing seems to work. Using mercurial, I got xen-3.2-testing.hg. I followed the steps in crashdb.txt in the docs/misc/ folder: set debug=y in Config.mk, crash_debug=y in xen/Rules.mk I also added -fno-omit-frame-pointer to these file as well. I compiled with no errors and booted with minicom connected to the workstation via com1 but when I do Ctrl-A three times to connect, nothing happens. The debuggee boots find and gives me the login screen as normal. Is there a special time to hit the Ctrl-A in minicom? Should the kernel wait for a connection from gdb? I''ve tried various combinations of using nsplitd and a serial-split patch I found mentioned on mailing lists and setting the boot flags to com=1H and com=1. Nothing seems to work. Is the gdb stub working with this version of the code? I have checked the serial connection by connecting minicom to the port and from the remote machine doing the command "echo test > /dev/ttyS0" and I receive the text. I have minicom set for 9600 8n1 and I use the same boot flags set in the grub config file. What am I missing? Thanks -matthew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I''m rather confused about what you''re trying to achieve. A good first step would be to get Xen console output over the serial line. You achieve this by specifying com1=115200 (for example) and console=com1,vga on Xen''s command line. If you can get that working then you can move onto the gdbstub. This requires: 1. that you add e.g. ''com1=115200 gdb=com1'' to Xen''s command line 2. you connect to the gdbstub with gdb, not with minicom! 3. Xen must crash for the gdbstub to be entered. The stub provides only post-mortem debugging analysis support -- Keir On 21/5/08 16:10, "Matthew Donovan" <matthew@atc-nycorp.com> wrote:> I am trying to debug the Xen hypervisor from a second computer over the > serial port, but nothing seems to work. Using mercurial, I got > xen-3.2-testing.hg. I followed the steps in crashdb.txt in the docs/misc/ > folder: > set debug=y in Config.mk, crash_debug=y in xen/Rules.mk > > I also added -fno-omit-frame-pointer to these file as well. > > I compiled with no errors and booted with minicom connected to the > workstation via com1 but when I do Ctrl-A three times to connect, nothing > happens. The debuggee boots find and gives me the login screen as normal. > Is there a special time to hit the Ctrl-A in minicom? Should the kernel > wait for a connection from gdb? > > I''ve tried various combinations of using nsplitd and a serial-split patch I > found mentioned on mailing lists and setting the boot flags to com=1H and > com=1. Nothing seems to work. > > Is the gdb stub working with this version of the code? > > I have checked the serial connection by connecting minicom to the port and > from the remote machine doing the command "echo test > /dev/ttyS0" and I > receive the text. I have minicom set for 9600 8n1 and I use the same boot > flags set in the grub config file. > > What am I missing? > > Thanks > -matthew > > _______________________________________________ > 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
On 21/5/08 17:43, "Matthew Donovan" <matthew@atc-nycorp.com> wrote:> Well, maybe I''m not going about this the right way then. > > Back in February, I asked some questions about getting the interrupt > descriptor table from an HVM guest with xc_vcpu_getcontext. You said the > only way to do it at the time was to do an hvm-save hypercall and parse the > binary. At the time, we put the whole issue to the side to get some other > things working first. Now we''ve come back to it and are looking at getting > an HVM''s IDT programmatically without doing the hvm_save() call. > > I''ve been looking at the source but I really wanted to be able to put in a > breakpoint and step through the code (if it''s possible) to see how > everything really interacts. > > If you can give me any direction (either for debugging Xen or getting the > IDT) I would really appreciate it.Well, debugging Xen and obtaining an HVM guest''s IDT details seem rather different things to want to do. What do you require the IDT details for? The right approach to obtain those details is to issue an hvm_save hypercall and then parse the returned guest state to find the IDT details for each VCPU. I can give yous ome more direction on this if that is what you need to be able to do. Getting serial gdbstub working is not the right path to that end. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Well, maybe I''m not going about this the right way then. Back in February, I asked some questions about getting the interrupt descriptor table from an HVM guest with xc_vcpu_getcontext. You said the only way to do it at the time was to do an hvm-save hypercall and parse the binary. At the time, we put the whole issue to the side to get some other things working first. Now we''ve come back to it and are looking at getting an HVM''s IDT programmatically without doing the hvm_save() call. I''ve been looking at the source but I really wanted to be able to put in a breakpoint and step through the code (if it''s possible) to see how everything really interacts. If you can give me any direction (either for debugging Xen or getting the IDT) I would really appreciate it. Thanks -matthew> -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Wednesday, May 21, 2008 11:45 AM > To: Matthew Donovan; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Debugging the hypervisor > > I''m rather confused about what you''re trying to achieve. A > good first step > would be to get Xen console output over the serial line. You > achieve this by > specifying com1=115200 (for example) and console=com1,vga on > Xen''s command > line. If you can get that working then you can move onto the > gdbstub. This > requires: > 1. that you add e.g. ''com1=115200 gdb=com1'' to Xen''s command line > 2. you connect to the gdbstub with gdb, not with minicom! > 3. Xen must crash for the gdbstub to be entered. The stub > provides only > post-mortem debugging analysis support > > -- Keir > > On 21/5/08 16:10, "Matthew Donovan" <matthew@atc-nycorp.com> wrote: > > > I am trying to debug the Xen hypervisor from a second > computer over the > > serial port, but nothing seems to work. Using mercurial, I got > > xen-3.2-testing.hg. I followed the steps in crashdb.txt in > the docs/misc/ > > folder: > > set debug=y in Config.mk, crash_debug=y in xen/Rules.mk > > > > I also added -fno-omit-frame-pointer to these file as well. > > > > I compiled with no errors and booted with minicom connected to the > > workstation via com1 but when I do Ctrl-A three times to > connect, nothing > > happens. The debuggee boots find and gives me the login > screen as normal. > > Is there a special time to hit the Ctrl-A in minicom? > Should the kernel > > wait for a connection from gdb? > > > > I''ve tried various combinations of using nsplitd and a > serial-split patch I > > found mentioned on mailing lists and setting the boot flags > to com=1H and > > com=1. Nothing seems to work. > > > > Is the gdb stub working with this version of the code? > > > > I have checked the serial connection by connecting minicom > to the port and > > from the remote machine doing the command "echo test > > /dev/ttyS0" and I > > receive the text. I have minicom set for 9600 8n1 and I > use the same boot > > flags set in the grub config file. > > > > What am I missing? > > > > Thanks > > -matthew > > > > _______________________________________________ > > 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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> What do you require the IDT details for?We''re working on a security service using VM introspection to monitor the state of a running guest. We''d like to include the IDT as part of that monitoring.> The right approach to obtain those details is to issue an hvm_savehypercall and then> parse the returned guest state to find the IDT details for each VCPU. Ican give> yous ome more direction on this if that is what you need to be able to do.That would be great. Thanks -matthew> -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Wednesday, May 21, 2008 12:40 PM > To: Matthew Donovan; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Debugging the hypervisor > > On 21/5/08 17:43, "Matthew Donovan" <matthew@atc-nycorp.com> wrote: > > > Well, maybe I''m not going about this the right way then. > > > > Back in February, I asked some questions about getting the interrupt > > descriptor table from an HVM guest with xc_vcpu_getcontext. > You said the > > only way to do it at the time was to do an hvm-save > hypercall and parse the > > binary. At the time, we put the whole issue to the side to > get some other > > things working first. Now we''ve come back to it and are > looking at getting > > an HVM''s IDT programmatically without doing the hvm_save() call. > > > > I''ve been looking at the source but I really wanted to be > able to put in a > > breakpoint and step through the code (if it''s possible) to see how > > everything really interacts. > > > > If you can give me any direction (either for debugging Xen > or getting the > > IDT) I would really appreciate it. > > Well, debugging Xen and obtaining an HVM guest''s IDT details > seem rather > different things to want to do. What do you require the IDT > details for? The > right approach to obtain those details is to issue an > hvm_save hypercall and > then parse the returned guest state to find the IDT details > for each VCPU. I > can give yous ome more direction on this if that is what you > need to be able > to do. Getting serial gdbstub working is not the right path > to that end. > > -- Keir > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 21/5/08 18:52, "Matthew Donovan" <matthew@atc-nycorp.com> wrote:>> What do you require the IDT details for? > > We''re working on a security service using VM introspection to monitor the > state of a running guest. We''d like to include the IDT as part of that > monitoring. > >> The right approach to obtain those details is to issue an hvm_save > hypercall and then >> parse the returned guest state to find the IDT details for each VCPU. I > can give >> yous ome more direction on this if that is what you need to be able to do. > > That would be great.Okay, then see xc_domain_hvm_getcontext() as defined in tools/libxc/xc_domain.c and provided by library libxenctrl. An example of its usage is in xc_domain_save.c -- first call is to get required size of the state buffer; second call fills the dynamically allocated buffer. Alternatively I think you can just make the buffer ''plenty big enough'', e.g. 64kB. The contents of the state buffer is a set of state records, format you can probably work out after looking in xen/include/public/hvm/save.h and the arch-specific header file xen/include/public/arch-x86/hvm/save.h. You''re looking for the hvm_hw_cpu structure, and the idt_base/idt_limit that it contains. You can then map pages of guest memory to walk its pagetables (based on cr0/cr3 values from the hvm_hw_cpu structure) and ultimately get a mapping of its IDT. And from there you can do what yoiu need to do... So overall it''s a pretty involved operation to get at the IDT. Whether it''s worthwhile depends on how badly you need it. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
We are seeing the following build error with xen-unstable c/s 18846. make[4]: Entering directory `/builddir/build/BUILD/xen-unstable/tools/ioemu-remote/i386-dm'' ../xen-hooks.mak:53: *** pciutils-dev package not found - missing /usr/include/pci ../xen-hooks.mak:54: *** PCI passthrough capability has been disabled ../xen-hooks.mak:53: *** pciutils-dev package not found - missing /usr/include/pci ../xen-hooks.mak:54: *** PCI passthrough capability has been disabled /builddir/build/BUILD/xen-unstable//tools/cross-install -d -m0755 -p "/var/tmp/xen-3.2.0-18846-root//usr/lib/xen/bin" /builddir/build/BUILD/xen-unstable//tools/cross-install -d -m0755 -p "/var/tmp/xen-3.2.0-18846-root//etc/xen" /builddir/build/BUILD/xen-unstable//tools/cross-install -m0755 -p qemu-ifup "/var/tmp/xen-3.2.0-18846-root//etc/xen/" /builddir/build/BUILD/xen-unstable//tools/cross-install -m 755 -s qemu-dm "/var/tmp/xen-3.2.0-18846-root/usr/lib/xen/bin" make[4]: Leaving directory `/builddir/build/BUILD/xen-unstable/tools/ioemu-remote/i386-dm'' make[3]: Leaving directory `/builddir/build/BUILD/xen-unstable/tools/ioemu-remote'' make[2]: Leaving directory `/builddir/build/BUILD/xen-unstable/tools'' make[2]: Entering directory `/builddir/build/BUILD/xen-unstable/tools'' make -C xenpmd install make[3]: Entering directory `/builddir/build/BUILD/xen-unstable/tools/xenpmd'' gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -I../../tools/xenstore -I../../tools/include -L../../tools/xenstore -lxenstore xenpmd.c -o xenpmd cc1: warnings being treated as errors xenpmd.c: In function ''write_battery_info_to_xenstore'': xenpmd.c:376: warning: call to __builtin___strncat_chk might overflow destination buffer make[3]: *** [xenpmd] Error 1 make[3]: Leaving directory `/builddir/build/BUILD/xen-unstable/tools/xenpmd'' make[2]: *** [subdir-install-xenpmd] Error 2 make[2]: Leaving directory `/builddir/build/BUILD/xen-unstable/tools'' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/builddir/build/BUILD/xen-unstable/tools'' make: *** [install-tools] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.69009 (%build) Thanks, Maturi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks. Fixed as c/s 18849. -- Keir On 02/12/2008 20:01, "Srinivas Maturi" <srinivas.maturi@oracle.com> wrote:> > We are seeing the following build error with xen-unstable c/s 18846. > > make[4]: Entering directory > `/builddir/build/BUILD/xen-unstable/tools/ioemu-remote/i386-dm'' > ../xen-hooks.mak:53: *** pciutils-dev package not found - missing > /usr/include/pci > ../xen-hooks.mak:54: *** PCI passthrough capability has been disabled > ../xen-hooks.mak:53: *** pciutils-dev package not found - missing > /usr/include/pci > ../xen-hooks.mak:54: *** PCI passthrough capability has been disabled > /builddir/build/BUILD/xen-unstable//tools/cross-install -d -m0755 -p > "/var/tmp/xen-3.2.0-18846-root//usr/lib/xen/bin" > /builddir/build/BUILD/xen-unstable//tools/cross-install -d -m0755 -p > "/var/tmp/xen-3.2.0-18846-root//etc/xen" > /builddir/build/BUILD/xen-unstable//tools/cross-install -m0755 -p > qemu-ifup "/var/tmp/xen-3.2.0-18846-root//etc/xen/" > /builddir/build/BUILD/xen-unstable//tools/cross-install -m 755 -s > qemu-dm "/var/tmp/xen-3.2.0-18846-root/usr/lib/xen/bin" > make[4]: Leaving directory > `/builddir/build/BUILD/xen-unstable/tools/ioemu-remote/i386-dm'' > make[3]: Leaving directory > `/builddir/build/BUILD/xen-unstable/tools/ioemu-remote'' > make[2]: Leaving directory `/builddir/build/BUILD/xen-unstable/tools'' > make[2]: Entering directory `/builddir/build/BUILD/xen-unstable/tools'' > make -C xenpmd install > make[3]: Entering directory > `/builddir/build/BUILD/xen-unstable/tools/xenpmd'' > gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 > -mtune=generic -fasynchronous-unwind-tables -O2 -fomit-frame-pointer > -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall > -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -O2 > -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 > -Wall -Wstrict-prototypes -Wno-unused-value > -Wdeclaration-after-statement -O2 -fomit-frame-pointer -m32 -march=i686 > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -O2 -fomit-frame-pointer > -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall > -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement > -D__XEN_TOOLS__ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -O2 > -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 > -Wall -Wstrict-prototypes -Wno-unused-value > -Wdeclaration-after-statement -D__XEN_TOOLS__ -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE > -mno-tls-direct-seg-refs -Werror -I../../tools/xenstore > -I../../tools/include -L../../tools/xenstore -lxenstore xenpmd.c > -o xenpmd > cc1: warnings being treated as errors > xenpmd.c: In function ''write_battery_info_to_xenstore'': > xenpmd.c:376: warning: call to __builtin___strncat_chk might overflow > destination buffer > make[3]: *** [xenpmd] Error 1 > make[3]: Leaving directory `/builddir/build/BUILD/xen-unstable/tools/xenpmd'' > make[2]: *** [subdir-install-xenpmd] Error 2 > make[2]: Leaving directory `/builddir/build/BUILD/xen-unstable/tools'' > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory `/builddir/build/BUILD/xen-unstable/tools'' > make: *** [install-tools] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.69009 (%build) > > Thanks, > Maturi > > > _______________________________________________ > 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