Trimming CC list, adding seabios list.
On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
On Sat, Nov 27, 2010 at 01:40:12PM -0500, Kevin O'Connor wrote:
On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote:
Qemu does not know that Seabios needs optionrom to boot from a device. It knows even less about bcvs in option rom. Qemu knows about device itself, not how firmware boots from it.
If the user wants to boot from a device and that device has an optionrom, then it's a safe bet that the optionrom is needed to boot from it.
Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can natively boot from has optionrom. What Seabios will do in such situation and how qemu can know it? Besides qemu support tries to be firmware agnostic.
In such a situation, under my proposal, users wouldn't be able to specify a default boot from their scsi drive until after qemu was also upgraded to know seabios could boot native scsi. (Or, they'd only be able to do it by adding in a command-line option.)
In any case, I'd rather have qemu know which devices seabios can boot then have seabios try to figure out what rom to run from a device path.
You run all of them just like you do now. Information you get from qemu is only used for sorting BCV/BEV entries. BCV/BEV that does not have corespondent boot path in boot order list is put at the end.
If qemu sends in "/pci@i0cf8/scsi@3/disk@0,0" or "/pci@i0cf8/ethernet@4/ethernet-phy@0" it will expect seabios to boot from the appropriate device. In both cases, seabios would need to run a rom in order to fulfill that request. Trying to figure out which rom is quite painful. That's why I'd prefer to see qemu instead pass in something like "/pci@i0cf8/rom@3/bcv@0" or "/pci@i0cf8/rom@4/bev". That is, if the machine needs to boot via a rom I'd prefer qemu state that explicitly.
BTW, in the situation where seabios has native device support (eg, ATA), I don't have any concerns. (The names are a bit verbose, but that's not really an issue.)
BTW are you actually aware of any option rom with multiple BCVs and, if yes, how those BCVs differ?
Multiple BCVs - yes. A SCSI card will define a BCV for each attached drive. I don't have a scsi card myself, but the support was added by a user who ran into the problem first hand.
Optionrom is static. How number of BCVs can depend on number of attached drives?
Not sure what you mean by "Optionrom is static". SeaBIOS unlocks the memory, and the optionrom can and will modify itself with additional PNP headers so that it can list multiple BCVs - one for each drive. In particular, gPXE uses self modification to relocate parts of itself into high ram.