[libvirt] [PATCH 0/4] allow OVMF users to disable qemu's "-boot strict=on"

Laszlo Ersek lersek at redhat.com
Tue Jan 28 12:33:22 UTC 2014

On 01/28/14 13:10, Daniel P. Berrange wrote:
> On Thu, Jan 23, 2014 at 05:25:18PM +0100, Laszlo Ersek wrote:
>> On 01/23/14 15:58, Daniel P. Berrange wrote:
>> I disagree that users setting their persistent boot variables form
>> inside the guest fall in the same category. That feature is an
>> unalienable part of UEFI.
>>> The goal we have is that the XML description should fully describe
>>> the configuration of a VM. Having a situation where the XML config
>>> only partially describes the setup, and the rest is delegated to
>>> a config embedded in the firmware image is not something we wish
>>> to support.
>> I understand.
>>> IMHO what we need to tackle here is the inability to properly
>>> configure the firmware boot order from QEMU / libvirt. ie make
>>> it possible for users to fully control it via libvirt XML.
>> We'd face two hurdles towards this goal.
>> - The first is that you'd need to get a basically free-form string
>> through. Technically it wouldn't be very hard, but it's completely
>> foreign from the current bootindex concept in libvirt/qemu.
>> In UEFI, "bootable device" can refer to something that's just a chunk of
>> guest RAM for qemu.
>> - The second hurdle is that you couldn't *offer* the host-side user sane
>> choices (device paths for UEFI boot options) beyond a limit. This is
>> because device paths come to existence by the execution and stacking of
>> UEFI drivers, and their binding to devices.
> Ok, I think I understand the problem more now. Would there be any sense
> in defining an generic <boot dev="config"/> option to indicate that UEFI
> should try the config settings that the user has defined inside the UEFI
> config partition ?

This probably makes sense, yes. It is identical to the case when no boot
order at all is passed down via fw_cfg.

(It is also identical to the case when some boot order *is* passed down,
but OVMF finds no match at all. In this case the UEFI boot order is not

> If we use the strict=on|off setting, the user's config
> settings are only usable as the very last fallback option, once all the
> explicitly listed options have been tried.


The idea behind the current code was:
- want to go fully with the existent UEFI boot order: pass no OFW boot
order over fw_cfg,
- want to reorder existing boot options (and drop the unselected ones,
except those in the "survival policy"): pass some OFW boot order via
fw_cfg and make sure there's at least one match.

> If we had a <boot dev="config">
> we would perhaps be able to express ordering such as
>    <boot dev="hd">
>    <boot dev="config">
>    <boot dev="cdrom">
> without having to invent a impossibly complicated grammer to express all
> possible UEFI bootable device options ?

What does this specification mean? Like,
- try to match "hd" against the UEFI boot options, and move it to the
beginning if it exists,
- same for "cdrom", but move it to the end,
- keep the rest in the middle?


More information about the libvir-list mailing list