Stefan Hajnoczi: GDB Remote Debugging

Milestones:

• [b44] Tested and clean for mainline review.
• [virtio] Port of etherboot virtio-net driver.

Commits:

• [virtio] Add Etherboot legacy driver
• [virtio] Use ETH_FRAME_LEN instead of ETH_MAX_MTU

Laurent Vivier sent a virtio-net driver for Etherboot. 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:

$ kvm -bootp http://etherboot.org/gtest/gtest.gpxe -no-kvm -net user -net nic,model=virtio bin/virtio-net.usb

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.

Commits:

• [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.

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.

On to Week 11.