On Tue, Jan 28, 2014 at 01:33:22PM +0100, Laszlo Ersek wrote: > 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? Roughly, but I'd expect 'hd' and 'cdrom' to be used against whatever HD and CDROM devices exist in hardware, regardless of what the UEFI setup currently is. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list