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

[Sebastian Herbszt]

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