Re: [Qemu-devel] nvram and boot order

[Alexander Graf]

On 18.10.2012, at 03:18, Benjamin Herrenschmidt <address@hidden> wrote:

> 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.

I think Anthony and you are looking at 2 different use cases, each with their 
own sane reasoning.

You want to have the chance to override the boot order temporarily for things 
like cd boot or quick guest rescue missions.

You also want to be able to permanently change the guest's boot order from a 
management tool. At that same place you want to be able to display it, so you 
don't have to boot your vm to know what it would be doing.

As for device detection logic, both face the same problems. You need to be able 
to say 'boot from cd-rom first temporarily' just the same as you need to be 
able to say 'boot from the first cd-rom as first boot option permanently'. The 
permanent change needs to be possible with the vm turned off though.

I suppose that Anthony's reasoning is that we can implement temporary in the 
management layer (or even qemu) if we have the permanent mechanism, by 
switching back to the previous state after shutdown if the guest written boot 
order didn't change.

I don't mind personally if we have one interface for temporary and persistent 
or 2 separate ones, but I think we should aim for having both options available 
in the long run. Though doing permanent changes first and reverting them later 
could raise problems when you kill your vm, since that wouldn't clean up the 
temporary change.

> 
> 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.

Yes, the same problem as EFI for example is facing. The solution here is as 
simple as it gets: a new device name space. Instead of having a boot list entry 
saying 'boot from device x, part y, file z' you would get an entry saying 'boot 
from /qemu/disk0' and leave the rest to the firmware. The good thing about this 
approach is that it again is persistable and can be used in boot order lists. 
So you can directly translate -boot cd into /qemu/disk0,/qemu/cdrom. And if you 
screwed up your guest boot config, just put that order in by hand into 
permanent config.

> 
> Qemu gives as much info as it can and let the firmware itself inside the
> guest figure things out.

Yes, that's the only chance we have really. Even for bootindex, which could for 
example get translated to /qemu/pci/0.10.0/disk0 which again would then get 
aliased to the actual disk device node behind pci device 0.10.0 (first disk) by 
SLOF.

> 
> 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 :-)

It might be useful to use fdt in nvram to store the permanent boot order. That 
way QEMU / management tools have the chance to make persistent changes. 
Everyone around already understands fdt anyways :).

> 
>> 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.

Yes :).

Regardless of this problem, I think the conclusion on how to gandle default 
-boot makes sense to everyone, so you (Avik?) can already start working on that 
one while we nail down the details of the boot protocol handshakes between QEMU 
and SLOF.


Alex