On Thu, 2012-10-18 at 11:09 +1100, David Gibson wrote: > > > That's horrible; if you use -boot just once it will clobber a > > > persistent NVRAM's boot order. I see that a means of changing the > > > default boot order from management tools is desirable, but that > > > shouldn't be the normal behaviour of -boot. And the objections to (2) > > > apply even more strongly - we'd need to translate arbitrary -boot > > > strings to NVRAM representation which may not be at all > > > straightforward from the information qemu has available. > > > > It may not be straight forward, but it's what makes the most sense from > > a user's PoV. > > Bollocks. Using -boot to override the normal boot sequence > permanently changing the normal boot sequence absoultely does not make > sense from a user's PoV.
I strongly agree with David here. -boot should not change the persistent state. In our case, the persistent state will have been carefully crafted by complicated scripts by the distro installer, and while I may want to use -boot to boot once off a cd image or similar, I certainly don't want that to affect my nvram setting pointing to the right on-disk bootloader. Additionally I don't want qemu to have to understand all the intricacies of expressing OFW boot path if we can avoid it. Qemu gives as much info as it can and let the firmware itself inside the guest figure things out. In fact, I don't want Qemu to know anything about our internal nvram format. This is a business between the guest FW and the guest OS. The only thing qemu is allowed to do is wipe it out if asked to do so :-) > Um.. as far as I can tell that's a point in favour of my position. It > makes it impossible for qemu to correctly describe boot sequences > using these devices in the terms firmware uses internally. On the > other hand it certainly is possible for qemu to pass bootorder="cd" > (or whatever) to the firmware via device tree of fw_cfg and have > firmware locally interpret that in tersm of what it knows about > available devices. This is more/less what happens with -boot today. IE. If you pass "c" SLOF looks for a bootable disk (though arguably the algorithm could be improved), "d" for a bootable optical media etc... We definitely want something a bit more expressive and in some case might even be able to pass down from the command line a full path to an actual device but we don't necessarily want qemu to understand the nvram format of this. Make it an expressive representation that makes sense to qemu, and let the FW "translate" that to something it understands internally. Cheers, Ben.
