So today was the day of the first Xen tests. Even though my laptop's keyboard didn't work with the Xen kernel, I figured that was a minor driver issue and if I get it to reach the login screen with gPXE, then it's okay. I realised then that the desktop was not configured as a boot server: no dhcp and no tftp servers. I only used it before for the forcedeth NIC and the laptop was the one with the dhcp and tftp servers. The roles were now reversed. The reason why I didn't keep the previous configuration is because Xen on my desktop gave an error related to a firmware bug, related to an ACPI, along with a message that I should upgrade my BIOS.

So I proceeded in installing and configuring the servers on the desktop PC which took a while because of my uberl33t admin skillz. After the setup was complete, I used ye old booting stick, containing a gPXE image with the b44 driver for the laptop's NIC. Well, we're sorry but the princess is in another castle :) Apparently, b44 NICs have limited number of address pins so they're not able to access addresses above 1GB. My laptop has 2GB of RAM :( I looked through the driver and even commented the >1GB check to see if perhaps it works but unfortunately it doesn't. Perhaps I shall look into this another time.

Meanwhile, I got a _new_ laptop these days and I was wondering if Xen would work on it. While configuring stuff on the PC this question kept bugging me. So, I went on and installed stuff on the new laptop, recompiled Xen, recompiled a dom0 kernel, initrd, modified GRUB and booted it. It reached the login screen, keyboard works (yay for improvements) but I didn't test Xen specific commands. I was now curious if gPXE would work with the r8169 NIC the new laptop has. Back to the booting stick, now equipped with and r8169 driver. Along came three words everybody wants to see: “Missing operating system”.

I figured this must be some SYSLINUX bug, because I tested the stick on the old laptop and it ran fine. Looking at the syslinux version I used to create the stick, it was 3.63. I downloaded the latest 4.02 SYSLINUX, compiled it, and used it to create a new booting stick. “Press CTRL+B to load gPXE…”. Yay :)

So it worked and I was able to fetch some dummy images. Eventually, I fetched the Xen hypervisor along with a dom0 linux image. The initrd had a size of 66M and after all the installing and apt-getting and whatnot I was tired of waiting.

imgfetch xen-4.0.1
imgfetch vmlinuz
imgload xen-4.0.1
imgload vmlinuz
imgexec xen-4.0.1

Amazingly enough, the hypervisor booted and even recognized the vmlinuz image (I am not sure how this happened since I didn't give any specific commands for this), and the Linux kernel froze because it didn't know how to access the root partition (because I didn't pass it any root= argument like in GRUB). At this point, I was happy with today's progress, and I was glad to see that the hypervisor worked.

Resumed the tests today. First thing I did was pass a “root=/dev/sda1” argument to the vmlinuz module, since apparently that was the problem yesterday. Also, I fetched the initrd. To my surprise, the hypervisor now reported that it could not find any dom0 kernels. I had a hunch this was related to the order I fetched the images so I tried fetching the initrd before the vmlinuz module. This worked and the kernel booted.

However, things can't be left in this state. I will have to modify the multiboot code so the modules are placed in proper order.

Non working order:

imgfetch vmlinuz
imgfetch initrd

MULTIBOOT 0x17514 module 0 is [b1f80000,bb8b1400)
MULTIBOOT 0x17514 module 1 is [bf9b5000,bfda2920)

Working order:

imgfetch initrd
imgfetch vmlinuz

MULTIBOOT 0x17514 module 0 is [b1f80000,b236d920)
MULTIBOOT 0x17514 module 1 is [b236e000,bbc9f400)

Git commit: 5a082f918accb57c8ba28cf1802705b42c96784c

Today I implemented the –nodecode option that allows an user to fetch an image without it being decoded. Also, I tried fixing the image order issue but it doesn't work yet. I have to find out exactly how gPXE is laid out in memory before I can properly solve this issue.

Unfortunately, due to time-constraints related to my departure, I am postponing the work on the multiboot patches until after GSoC.

To sum up my work this summer:

• pcnet32 driver link
• forcedeth driver link
• small patch related to MAC address handling, code ported from Linux link
• small patch for r8169 driver link
• improve multiboot code so that Xen, VMware ESXi and Solaris work properly. This is still a work in progress. In the current state, gPXE + Xen hypervisor + dom0 kernel + initrd work with the small catch that the initrd has to be fetched first.

• Google, for making this possible
• The gPXE team, for accepting me as their student this summer
• stefanha, for providing invaluable help on a day-to-day basis and taking his time to explain things thoroughly
• mdc,meteger, for helping me with debugging the drivers and moral support
• oremanj, for insight into the decoding infrastructure
• GuoFuTseng, for testing my forcedeth driver
• peper, for his role in me learning how to properly format a patch :)

If I have forgotten anybody, I apologize, but know that your help was used in making the above patches possible.

Great summer, awesome project, I hope to able to contribute to it further. GG!