On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote: > On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote: > > On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote: > > > On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote: > > > > I am using open firmware naming scheme to specify device path names. > > > > In this version: added SCSI bus support. Pass boot order list as file > > > > to firmware. > > > > > > > > Names look like this on pci machine: > > [...] > > > > /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0 > > > > /rom@genroms/linuxboot.bin > > > > What's the plan for handling optionroms (ie, BCVs and BEVs)? This is > > an area which is a bit tricky - mainly due to legacy BIOS crud. > > > > An option rom can register either a BEV (eg, gpxe on a network card), > > or it can register one or more BCVs (eg, a scsi card registering two > > drives). How do we say boot from the optionrom on the second nic > > card? If you have a scsi card, how do we communicate that its second > > drive should be the c: drive? > > > BEV should be easy. When you register BEV found on pci card you search > for device path to that pci card to determine BEV's boot order. SeaBIOS has two separate optionrom passes - one to extract the roms from the cards and one to find BEVs and BCVs. In order to correlate a rom to a pci device SeaBIOS would have to keep track of each rom it deploys and then correlate it during the BEV/BCV scan. >BCV > should be the same, but since one PCI card may register several > BCVs the problem is more complex. Device path has not only path to > SCSI PCI card but to specific target,lun too. For instance this path > /pci@i0cf8/scsi@3,2/disk@0,0 points to SCSI card in pci slot 3 function 2 > target 1 lun 1. The question is if BCV provides us with enough information > to know what target/lun it is going to boot. How will seabios even know it's a SCSI card? All seabios sees is a PCI device with a valid option rom bar. Further, I don't see how seabios will know which BCV is which lun. BTW, I assume you're suggesting that if a disk is found first in the list then seabios should make that drive the c: and make hard drive booting be the first thing attempted? (This is what the seabios boot menu does.) > > The ugly thing about BCVs is that they are not necessarily registered > > in the rom for the device that controls it. So, if you have two of > > the same type of scsi card, each with two drives, it's possible for > > the optionrom to put all four drives in the rom of the first scsi > > card. > > > That just broken optionrom. I can't see how we can solve this without > communicating with such optionrom and letting it know what device we > want to boot from. I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically states that optionroms can do this. I don't know how many roms actually do it. The BCV and BEVs have a "product name string" that could be used to identify which one to boot. Unfortunately, there isn't a good way for qemu to find these strings (though maybe it could just hard code them for roms it ships with). SeaBIOS does show them in the boot menu, so a user could manually copy them to a command line. >There can be also legacy optionrom that just hooks > into int19 during init and hijack booting process entirely. I think > those problems exist on real HW too. That's a separate problem which I wouldn't worry too much about. The only roms that I've seen do this today are roms we have the source for and can change. -Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
