qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: qdev property bug?


From: Kevin O'Connor
Subject: Re: [Qemu-devel] Re: qdev property bug?
Date: Mon, 14 Dec 2009 23:23:30 -0500
User-agent: Mutt/1.5.19 (2009-01-05)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]