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

[Anthony Liguori]

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. 

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.

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

> > Currently, the only roms we load are pxe roms or things specified by  
> > -option-rom.  You could certainly argue that making -option-rom higher  
> > priority than implicit pxe roms is valuable but removing the pxe roms  
> > really serves no purpose.
> >
> > Regards,
> >
> > Anthony Liguori
> >     
>
> I am concerned about management.  User selects "PXE support" when
> creating VM, and creationg succeeds, but in fact PXE can not work
> because we can not shadow the ROM.
>
> Sounds bad. If device creation failed,
> user would get feedback when it is expected.
>   

It's unfortunately much more complicated than this :-/

Ignore the case of one nic, that should Just Work today.

If you have two nics, even if we are able to load both roms, we have no 
way of communicating to the bios that we want to use one BEV device vs. 
another.  That means if you have two nics that are both capable of pxe 
booting, '-boot n' really cannot be used to determine which one actually 
gets to pxe boot.

We'll have the same problem with BCV based extboot.  We really need to 
improve -boot to support things other than the concept of "first disk" 
and "first nic".

That's why I'm a fan of the intermediate solution of just stopping 
loading roms when we run out of room.  It's just as well defined 
behavior as we have even if we could load more roms.

Regards,

Anthony Liguori