On Mon, Dec 14, 2009 at 03:05:22PM -0600, Anthony Liguori wrote: > I believe the way this works with real BIOSes is that the rom is > initially loaded somewhere outside of the 1M region and it's init is > executed. It's then the rom's job to execute it's initialization. > Afterwards, the bios copies the rom into the 1M region. This is how PMM > works.
The option rom load is generally a little different. The BIOS enables the PCI rom bar, verifies the rom, copies the rom to the 0xa0000-0xf0000 region, unmaps the PCI rom bar, and then jumps to the rom it just copied. The rom may reduce its reported rom size to effectively shrink its memory footprint. As you noted in another post, gPXE does this today by relocating itself into PMM allocated memory. The PCIv3 spec does define a feature where the bios can copy the rom to some random area of memory and execute it - the rom is then responsible for copying itself into the 0xa0000-0xf0000 region. However, this support is optional for the BIOS to implement; SeaBIOS doesn't implement it. Having SeaBIOS copy the roms from PCI space enables a number of space optimizations. First, if SeaBIOS copies the roms, it can pack them so that rom shrinking actually works. As it is now, a rom can shrink itself, but because SeaBIOS doesn't deploy the roms, the saved space isn't utilized for other roms. Second, SeaBIOS right now is about 75K in size, but to satisfy qemu it fills itself to an even 128K. When SeaBIOS copies roms, it knows it can use the unused parts of the e-segment (another 50K). One idea I've been thinking about is to have SeaBIOS hoist it's 32bit code into high-memory (much like what gPXE does). This would make the remaining parts of the e-segment available for roms. It would also free up another 30K of the f-segment for roms (the PCIv3 spec permits roms to be located in the f-segment). However, implementing this doesn't seem like a high priority as most roms seem to fit okay today (when rom shrinking works). -Kevin