qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCHv6 00/16] boot order specification


From: Gerd Hoffmann
Subject: [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
Date: Mon, 29 Nov 2010 11:50:45 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100827 Red Hat/3.1.3-1.el6 Thunderbird/3.1.3

  Hi,

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.

Try to keep track of which bcv/bev belongs to which pci device? It should surely work for devices supported by seabios natively. SeaBIOS should also know which device's rom registered which entry. It might become tricky though in case there are multiple identical devices are present, say two e1000 cards, where the first rom could register entries for both cards ...

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:

/address@hidden/address@hidden/address@hidden
/address@hidden/address@hidden

SeaBIOS will ignore the first entry, and act on the second entry.

SeaBIOS should be able to operate just fine with the first entry. "address@hidden" means "the nic at bus address 4". As this is a PCI bus "4" is the pci address. So SeaBIOS would just look what entries it has for "00:04.0", run the rom, and ignore the "/address@hidden" part as it can't handle it.

In case of scsi seabios can look at the next path element to figure the scsi id. With native support it should be able to boot the correct disk directly. When booting via rom it can either just pick the first entry unconditionally (probably good enougth in 99% of the cases) or do some guesswork based on the order the entries are registered.

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?

fn is optional for fn=0, IIRC the syntax is "address@hidden,$fn".

Bus is specified via location in the tree, i.e. you'll see the bridge for the secondary pci bus in the path, like this:

/address@hidden/address@hidden/address@hidden/...

(not sure it is actually named 'bridge' in the openfirmware specs though).

cheers,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]