Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
soc:2008:stefanha:journal:week10 [2008/07/30 07:46] stefanha created |
soc:2008:stefanha:journal:week10 [2008/08/08 05:16] (current) stefanha |
||
---|---|---|---|
Line 8: | Line 8: | ||
==== Wed 30 Jul ==== | ==== 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]] | ||
- | Next steps: | + | **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. |
- | * [virtio] Do we need a native gPXE virtio driver? | + | |
- | * [GDB] Add sample GDB session to wiki and explain commands | + | 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: |
- | * [DMA] DMA pool API so drivers can reserve DMA buffers on ''open()''. | + | <code> |
- | * [b44] Cleanup, testing, performance. | + | $ kvm -bootp http://etherboot.org/gtest/gtest.gpxe -no-kvm -net user -net nic,model=virtio bin/virtio-net.usb |
- | * [shutdown] Remove gPXE allocated memory and free up PXE+UNDI, if necessary. | + | </code> |
- | * [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. | + | **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 Week ===== | ||
+ | On to [[.:week11|Week 11]]. |