Stefan Hajnoczi: GDB Remote Debugging

Milestones:

• [b44] Tested and clean for mainline review.
• [gpxelinux.0] Merge Award BIOS return-to-PXE workaround.

Git commit: [init] Shutdown flags for fine-grained exit behavior

Time is passing quickly. Today I worked on fine-grained shutdown(). There are two scenarios under which shutdown() is called:

1. Booting an image that does not use gPXE interfaces (like BIOS int 13h or PXE). Here everything should be cleaned up and shut down.
2. Exiting gPXE to return control to firmware (usually to boot the next device if gPXE failed). Here we may wish to leave some resources, like the underlying PXE stack, running.

There is currently no way to distinguish these two cases for shutdown(). Therefore, we are not able to clean up or leave resources as appropriate.

I have added a flag to shutdown() to indicate either SHUTDOWN_BOOT or SHUTDOWN_EXIT. As part of undionly.kpxe, we need to unload the PXE base code if shutdown(SHUTDOWN_BOOT) is performed. I still need to figure out how to do the unloading and freeing of base memory…

Git commit:

• [prefix] kkpxe prefix for keep UNDI, return-to-PXE images

Sent the e820mangler.S patch for full clipping into fragments for review today.

Created .kkpxe image type for PXE images that keep PXE+UNDI loaded and return to PXE (instead of int 18h). Here is a gpxelinux.0 image built from undionly.kkpxe.

Sent gpxelinux merge patches for review. I spent some time this week working on fine-grained shutdown() so that gPXE can free resources appropriately. However, I believe that this work is independent of the gpxelinux merge and our priority is to get gpxelinux merged. Therefore, I have submitted the gpxelinux patches now, without fine-grained shutdown().

Git commit: [image] Multiple embedded images and no hardcoded DHCP

Users who want a static IP address instead of DHCP find they need to edit the source to remove hardcoded DHCP. They can then use the EMBEDDED_IMAGE build option to include a gPXE script that configures their static network settings inside the gPXE binary.

Since editing the source is inflexible, there is a discussion to change gPXE's behavior to something more general than hardcoded DHCP. The new policy would skip DHCP for embedded images since they likely want to set up network settings themselves.

While this solves the problem for embedded gPXE scripts which do their own network configuration, it breaks when pxelinux.0 is embedded inside gPXE. PXELINUX expects the network interface to be (auto-)configured.

I think the most general way to solve this dilemma is by allowing multiple embedded images and making gPXE always boot from an embedded image. Even when you build without explicit EMBEDDED_IMAGE settings, a default gPXE script is built in.

Anyway, I have created a multiembed branch with these features implemented. I think most of this solution has already been thought about by hpa, mcb30, and mdc. I just wanted to code something last night; hope this is a step in the right direction.

Update: removed detailed description since the reworked patch changes things slightly. See newer entry.

Back to the b44 driver, I have removed uhmalloc and am using malloc's allocator instead. Once this reworking is complete, I can move up to the DMA mapping API to support DMA pools. Then I will send these patches for review and merge before sending the actual b44 driver.

Sent cleaned up gpxelinux merge patch for mainline review.

Git commits:

• [image] Make dependencies for EMBEDDED_IMAGE
• [image] Clean up embedded image support

Reworked multiembed patch. The following text documents the user-visible changes:

gPXE normally fetches images over the network using TFTP, HTTP, iSCSI, or other network protocols. It is also possible to embed an image file inside gPXE and make it available without fetching over the network.

By embedding gPXE scripts, you can customize gPXE's behavior before its first network access. For example, static network configuration can be done by embedding a gPXE script.

Images are embedded when building gPXE with make:

$ make EMBEDDED_IMAGE=../contrib/scripts/static.gpxe

This builds a gPXE image which executes the static.gpxe script on startup. The static.gpxe sample script works with QEMU's user network stack:

#!gpxe
ifopen net0
set net0/ip 10.0.2.15
set net0/netmask 255.255.255.0
set net0/gateway 10.0.2.2
set net0/dns 10.0.2.3
kernel http://etherboot.org/gtest/gtest.gpxe
boot

Multiple images can be embedded:

$ make EMBEDDED_IMAGE=../contrib/scripts/gpxelinux.gpxe,/usr/lib/syslinux/pxelinux.0

This builds a gPXE image which executes the gpxelinux.gpxe script on startup. The gpxelinux.gpxe script performs DHCP before loading the embedded pxelinux.0 image and executing it:

#!gpxe
dhcp net0
imgload img1
boot

Why did we write imgload img1 and not imgload pxelinux.0? Embedded images are automatically named img# starting from img0. They do not retain their original filenames. For example:

$ make EMBEDDED_IMAGE=first.gpxe,second.gpxe,third.gpxe
                      ^ img0     ^ img1      ^ img2

Also, notice that we had to use imgload before doing boot. This is because embedded images are not automatically loaded for booting. They are simply available as if they had been fetched using imgfetch.

The full behavior is described as follows. When gPXE starts, it does the equivalent of imgfetch for every embedded image and assigns them names starting with img0 for the first image. Then it loads and boots the first image (img0). If booting img0 fails, it removes all embedded images and gives up.

This paragraph does not apply to the multiembed code in gPXE mainline. It's interesting to note that gPXE always embeds an image, even if you do not give it one. By specifying an embedded image, you are overriding the default embedded image. The default embedded image is a script that tries DHCP booting from each network interface in turn:

#!gpxe
autoboot

Limitations of my patch:

• The semantics of replacing autoboot() with embedded images are not 100% compatible with past gPXE behavior. The autoboot process will bring up each network interface in turn using DHCP and attempt to run the embedded image or fetch a file from the network. Now, embedded images run only once and without any network interface being up or configured.

On to Week 9.