Re: [Qemu-devel] nvram and boot order

[Blue Swirl]

On Thu, Oct 18, 2012 at 6:32 AM, Alexander Graf <address@hidden> wrote:
>
>
> 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.

For comparison, QEMU passes boot device flag (c/d) to OpenBIOS, which
translates it to either first disk or cdrom. Then we have -prom-env
which can be used to pass further paths (/iommu/sbus/esp/address@hidden,0:/unix)
but this is controlled by user. OpenBIOS does not understand bootindex
yet, neither QEMU can't generate useful paths at least for Sparc32. So
far I have been thinking that bootindex would equal OFW boot path, but
why would that not work?

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