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

["Sebastian Herbszt" <herbszt@gmx.de>]

Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote:
>>   
>>> Because it can be selected by the user via the menu and because it can  
>>> be selected at runtime via the boot_set monitor command.
>>>     
>>
>> Yes, but it's not like we have nowhere to store them.
>> We could shadow ROM when it is actually needed.
>>   
> 
> 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 idea is that while outside of the 1M region, the rom can eliminate 
> unnecessary code and update it's own header to reflect it's new, 
> improved code size. 

It's more like the following (pci 2.2):
- enable and map expansion rom bar
- find rom and copy to ram (0xC000-0xDFFFF)
- disable expansion rom bar
- call rom init
- rom might resize itself (DDIM)
- write protect rom

PMM doesn't have (anything?) to do with this and the rom doesn't have to be loaded
outside of 1MB.

> I don't know whether gpxe will actually reduce it's size as part of this 
> process so it may not matter.  After running the option roms init 
> vector, the rom must be relocated into the option rom space though so 
> even this technique is not a solution unless gpxe is able to discard a 
> lot of bits it doesn't need.

gPXE supports DDIM.

>>> Also, the comment about "wasting memory" not quite accurate.  The memory  
>>> region in question is only used for roms.  If we didn't put roms there,  
>>> it would go to waste.
>>>     
>>
>> Some BIOSes I saw have an option not to use the first 1M for rom
>> shadowing :). Seriously as you see we are already
>> running out of that 1M.
>>   
> 
> I think that's just the first phase of rom loading.

- Sebastian