On Sun, Nov 28, 2010 at 08:00:29PM +0100, Peter Stuge wrote: > Gleb Natapov wrote: > > There is no way for qemu to know about BCVs or BEVs > > This is very much the key point. > > In order to have command line control over the boot process, the > machine and the firmware must agree on things. > > I see two options: > > 1. QEMU works very very hard to provide a machine that will result in > a particular BBS program flow in firmware, in the end resulting in > the desired device being used for booting - as long as QEMU and the > firmware happen to have the same understanding of the BBS. > Since qemu knows nothing about BCVs and BEVs it can't implement 1 since it can't know what BBS flow will look like in Seabios. > 2. QEMU passes boot instructions to the firmware based on immediate, > common, structured data. What is this "immediate, common, structured data"? This is the crux of the problem really. > > The first option seems disgusting to me, because it has many > drawbacks and no benefits. > > The second option requires inventing something that goes beyond the > established BIOS standards, maybe a reason for it to see fierce > resistance, but it is the only thing that makes sense. > > Specifying boot device using PCI BDF is a great example of using > common structured data. That BDF exists both in machine and firmware > data models. The scope of BBS is limited to the firmware, so it is > not really practical for creating consistency in a dynamic machine. > B from BDF does not exists in machine data model. -- 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