[libvirt] [Qemu-devel] [Qemu PATCH v2] add a boot option to do strict boot

[Laine Stump]

On 01/09/2013 10:52 AM, Amos Kong wrote:
> On Wed, Jan 09, 2013 at 08:14:07AM -0700, Eric Blake wrote:
>> On 01/09/2013 01:39 AM, Amos Kong wrote:
>>> Current seabios will try to boot from selected devices first,
>>> if they are all failed, seabios will also try to boot from
>>> un-selected devices.
>>>
>>> We need to make it configurable. I already posted a seabios
>>> patch to add a new device type to halt booting. Qemu can add
>>> "HALT" at the end of bootindex string, then seabios will halt
>>> booting after trying to boot from selected devices.
>>>
>>> This option only effects when boot priority is changed by
>>> bootindex options, the old style(-boot order=..) will still
>>> try to boot from un-selected devices.
>>>
>>> v2: add HALT entry in get_boot_devices_list()
>>>     define boot_strict to bool
>>>
>>> Signed-off-by: Amos Kong <akong at redhat.com>
>>> ---
>> Libvirt will need to expose an attribute that lets the user control
>> whether to use this new option; how do we probe via QMP whether the new
>> -boot strict=on command-line option is available?
>
> Old style to adjust boot priority by order parameter:
> -boot order=n,strict=on (BAD, unselected devices will be tried)
>
> New style to adjust boot priority by bootindex:
> -device virtio-net-pci,...,bootindex=1 -boot strict=on (OK)
>
> We only want strict option to support new style.
>
> (those two styles are implemented in two different way insider
> seabios, the latest simple patch only changed the bootindex way)

Just a note about this: as far as I can tell virt-manager currently only
uses the "old style" of specifying boot order; it needs to be enhanced
to recognize the presence of bootindex=n ordering, and behave
accordingly. Looking from the outside, that looks to be not completely
trivial, as the old style of ordering only allows specifying "hard disk"
as a single line in the priority order, but the new style has each disk
specified separately. Not only that, but *which* of the disks is tried
first under the old order may change depending on whether or not a
bootmenu is requested (in one case it picks unit=0 on the controller, in
the other case, it orders the disks alphabetically by target dev name)