On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote: > Hi Gleb, > > On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote: > > Anthony, Blue > > > > No comments on this patch series for almost a week. Can it be applied? > > My apologies - I haven't had time to review. > > > 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. 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. Another problem is with device passthroug where if we pass entire SCSI PCI card to a guest we cannot specify particular target to boot from. This can be solved by allowing adding boot device paths from command line. For SCSI the optimal solution would be to have SCSI support for device QEMU emulates built in in Seabios itself. It is just that current device QEMU emulates is so old and so buggy that it is not worth to support it. > 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. 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. -- 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
