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 touched.) > 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. Yes. 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? Thanks, Laszlo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list