On Tue, Nov 30, 2010 at 09:53:32PM -0500, Kevin O'Connor wrote: > On Tue, Nov 30, 2010 at 04:01:00PM +0200, Gleb Natapov wrote: > > On Mon, Nov 29, 2010 at 08:34:03PM -0500, Kevin O'Connor wrote: > > > On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote: > > > > 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. > > > > > > I'm having a hard time letting go of string matching. I understand > > > all the info is there if SeaBIOS parses the string. However, I think > > > parsing out openbios device strings is overkill in an x86 bios that > > > just wants to order the boot objects it knows about. > > > > > > Is there an issue with qemu generating two strings for devices with > > > roms? > > > > > I just do not see how I can justify this addition to qemu maintainers > > given that the parsing code below is very simple. > > It doesn't look correct to me - it doesn't handle the case where the > PCI device is on a bridge. > This is because Seabios does not yet keep pci bus topology information. Given this information it is very easy to add bridge support to my code. dev_path_get_node() returns pointer to next node for purpose :) > BTW, what's the plan for handling SCSI adapters? Lets say a user has > a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3 > bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from > lun3. I understand this use case may not be important for qemu, but > I'd like to use the same code on coreboot. Being able to boot from > any drive is important - it doesn't have to autodetect, but it should > be possible. > We can't. Option rom does not give us back enough information to do so. Form device path we know exactly what id:lun boot should be done from, but pnp_data does not have information to map BCV back to id:lun. I do not see how coreboot can provide better information to Seabios then qemu here. BTW to create proper EDD entry for SCSI boot device BIOS also needs too map BCV to id:lun. How it can be done? SCSI _is_ important for qemu. Not HBA we have now, but something supported by recent operation systems out of the box. When such HBA will be emulated in qemu we will add native Seabios support for it. -- Gleb. -- 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
