Re: [PATCHv6 00/16] boot order specification

[Gleb Natapov <gleb@redhat.com>]

On Sun, Nov 28, 2010 at 12:15:44PM -0500, Kevin O'Connor wrote:
> 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.
> 
Suppose we have "/pci@i0cf8/scsi@3/disk@0,0" with boot index 5 in
boot devices list and suppose pci device in slot 3 function 0 has
optionrom. When Seabios load the option rom from device to memory it looks
for string that matches "/pci@i0cf8/.*@3.*" if the string is found option
rom gets boot index from it. In our case "/pci@i0cf8/scsi@3/disk@0,0"
will match and optionrom will get boot index 5. In practice Seabios will
know that device is SCSI by reading device class so it will be able
to construct string "/pci@i0cf8/scsi@3" and use simple strstr to find
matching device path.

> >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.)
> 
See above. But for some device paths "ignore it" is acceptable answer (is
Seabios can't boot from it and device doesn't have optionrom).

> > > 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.
I still do not see why such rule is needed. Why information this patch
set provides is not enough?

> 
> > > 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?
This is not fragile since class to name translation is defined
by the spec. But even that is not required if Seabios will be a
little bit smarter and will implement fuzzy matching. i.e do not
match "/pci@i0cf8/ethernet@4/ethernet-phy@0" exactly but match
"/pci@i0cf8/.*@4.*" instead.

> 
> 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
> 
This patch series implement device paths as defined by Openfirmware
spec. /pci@i0cf8/rom@4 sould be out of spec. But I do not see why Seabios
can't build later from the former. Also I do not see why it would be
needed at all.

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

If you let go to the idea of exact matching of string built by qemu in
Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0
provides everything that Seabios needs to know and even more. If
you ignore all the noise it just says "boot from pci device slot 4 fn
0". Seabios may have native support for the card in the slot or it can
use option rom on the card. Qemu does not care.

> 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?
> 
Bus numbers are assigned by a guest. Qemu knows nothing about them, so
it specify device path by topology.  If pci bridge is present device
path will look like this:
/pci@i0cf8/pci@2/ethernet@4,1/ethernet-phy@0.
This path point to device in slot 4 fn 1 sitting on pci-to-pci bridge
in slot 2 fn 0 of host pci controller. Same is true for usb bus.

--
			Gleb.