This is an old revision of the document!
====== Stefan Hajnoczi: GDB Remote Debugging ====== ===== Week 10 ===== **Milestones:** * [b44] Tested and clean for mainline review. * [virtio] Port of etherboot virtio-net driver. ==== Wed 30 Jul ==== Commits: * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=170c17754c64ed46e98966de858028911935cbe4|[virtio] Add Etherboot legacy driver]] * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=1dde791f9ced510e7b317d7b129f34e39e23d0ef|[virtio] Use ETH_FRAME_LEN instead of ETH_MAX_MTU]] **Laurent Vivier sent a virtio-net driver for Etherboot**. [[http://lwn.net/Articles/239238/|Virtio]] is an API for virtualized device I/O. The Linux kernel only needs one virtio network driver, for example, and various virtualization projects like KVM, Xen, and lguest can make use of that paravirtualized driver. Without virtio, each virtualization solution would end up implementing their own guest drivers. Since the development effort is focused on gPXE rather than Etherboot, we are making virtio-net available in gPXE as well as Etherboot. I wrapped Laurent's driver using gPXE's legacy driver support and just **HTTP booted over the virtio-net driver from gPXE** for the first time: <code> $ kvm -bootp http://etherboot.org/gtest/gtest.gpxe -no-kvm -net user -net nic,model=virtio bin/virtio-net.usb </code> **Note gPXE hangs under KVM-70**, at least Debian's ''kvm-70+dfsg-1'' package. For some reason it enters an infinite loop (or is so slow I have not waited for it to finish) in ''arch/i386/prefix/unnrv2b.S'' ''decompress16''. The same command-line runs fine when "kvm" is replaced by "qemu" and the CPU registers are identical between KVM and QEMU before calling the function. I have not investigated further since gPXE loads successfully under KVM-72. ==== Thur 31 Jul ==== Commits: * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=0cba7e4fca1fbb8113aff33a57b8ad84f05e6c00|[image] Make embedded images user accessible]] **Embedded images are now accessible from the gPXE shell**. Mcb30 suggested keeping embedded images loaded so that users can access them from the gPXE shell. This could be helpful for debugging or simply experimenting with gPXE. I'm not sure if the current patch will make it into mainline since it makes the "boot" command without arguments unusable - the primary embedded image is loaded, plus whatever the user loaded manually, and gPXE doesn't know which one you want to boot when no argument is given. ==== Fri 1 Aug ==== **Debugging gPXE KVM issues** where we experience hangs. The problem has been narrowed down and seems to be related to interrupt dispatch. The ROM prefix code implements a timeout loop which hangs under KVM because the timer counter is not changing. Laurent Vivier is investigating this and has found that inserting ''nop'' instructions makes the problem go away. **It's time to work through my TODO list** instead of playing with new things that come along. I really want to get the b44 driver into mainline and have not spent the time needed to get the code ready. Next steps: * [GDB] Add sample GDB session to wiki and explain commands * [e820] Try inverting the hidden regions list to an "allowed" regions list. Do e820 mangling as the intersection between e820 regions and the "allowed" regions. * [DMA] DMA pool API so drivers can reserve DMA buffers on ''open()''. * [b44] Cleanup, testing, performance. * [shutdown] Remove gPXE allocated memory and free up PXE+UNDI, if necessary. * [bzImage] Expand the heap size to the full 64K segment when loading a bzImage kernel with version 2.02 or higher. * [GDB] Real-mode remote debugging.
