On Sun, Nov 28, 2010 at 09:45:34AM +0200, Gleb Natapov wrote:
On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote:
On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
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.)
If scsi card has optionrom with only one bcv then Seabios can determine its boot order from device path, so why not provide user with this option today?
It's unclear to me how SeaBIOS is supposed to do that.
Besides qemu may be used to emulates sparc with openbios and this combination may be able to boot from scsi device. Qemu is not just x86 emulator running Seabios. If there is problem with scsi boot we let management know, so it will not create unbootable configuration. Today it is impossible to boot guest from scsi in qemu btw.
Qemu can send in "/pci@i0cf8/scsi@3/disk@0,0" - it's just unclear what seabios is supposed to do with it. (If "ignore it" is the answer, that's fine with me.)
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.
It is painful in Seabios it is impossible in qemu at all. There is no way for qemu to know about BCVs or BEVs in optionroms especially considering that they are created at runtime like you say bellow.
It's not impossible - qemu could code up rules for when to request a rom boot and when to request a native boot. That may seem ugly, but (as near as I can tell) it's basically what you've asked seabios to do. If nothing else, qemu has the option to let the user pass in an explicit request via the command-line.
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.)
This + network booting are the may use case really. And I do not see what problem we have with BEV devices. "/pci@i0cf8/rom@4/bev" is not much different from "/pci@i0cf8/ethernet@4/ethernet-phy@0" since there can be only one bev per pci device. It is easy for Seabios to see that to boot from pci device in slot 4 func 0 it has to execute BEV.
I'm still stuck on how seabios is supposed to know it's an ethernet card. Sure, seabios could hardcode translations from classid to strings, but that seems fragile. What happens when the user wants to boot from myranet, or fiberchannel, or whatnot?
Maybe we can compromise here - if the user selects booting from a device, and qemu sees there is a rom for that device, then qemu can specify two boot options:
/pci@i0cf8/ethernet@4/ethernet-phy@0 /pci@i0cf8/rom@4
SeaBIOS will ignore the first entry, and act on the second entry. If at some later point seabios knows how to natively boot from the device (eg, scsi), then it will use the first entry and ignore the second.
BTW, how are PCI locations specified in these paths? They should have a (bus, dev, fn) - your examples only seem to show dev. How are the other parts specified?
-Kevin