Stefan Hajnoczi: GDB Remote Debugging

Milestones:

• [b44] Tested and clean for mainline review.

Ouch, lowest productivity this week. I am visiting my family and have spent time with friends, swimming, studying for the theory driving test, and organizing for the end of student life and the start of work in October .

After chatting with Marty today I am focusing again. Discussing Etherboot inspires me to get back to coding!

DMA mapping currently provides a mechanism to “sync” dynamically allocated memory with DMA-capable memory. This allows drivers to update their snapshot of memory shared with the device, or for the driver to change memory seen by the device.

The sync works by copying memory from the source region to the destination region. Drivers that use DMA mapping therefore pay a memory copy performance penalty.

There is a way to avoid syncing which I would like to explore. It also plays well with the concept of DMA pools (memory regions set aside as DMA memory). DMA pools mean that drivers must declare their intention to use DMA memory and reserve an amount of memory. We need to do this because gPXE should not change the memory map once it has been started.

Next steps:

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