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

On 01/22/14 12:45, Laine Stump wrote: > On 01/22/2014 12:45 PM, Daniel P. Berrange wrote: >> On Wed, Jan 22, 2014 at 01:33:18AM +0100, Laszlo Ersek wrote: >>> Recently, >>> >>> commit 96fddee322c7d39a57cfdc5e7be71326d597d30a >>> Author: Laine Stump <laine(a)laine.org&gt; >>> Date: Mon Dec 2 14:07:12 2013 +0200 >>> >>> qemu: add "-boot strict" to commandline whenever possible >>> >>> introduced a regression for OVMF guests. The symptoms and causes are >>> described in patch 3/4, and in >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1056258 >>> >>> Let's allow users to opt-out of "-boot strict=on" while preserving it as >>> default. >> I don't really get from that bug description why this can't be >> made to work as desired in OVMF. It seems like its is just a >> bug in the OVMF impl that it doesn't work. > > I was on the verge of making that same comment in question form. From > the information in the patches and the BZ, it sounds like either "--boot > strict" is implemented incorrectly for OVMF, or OVMF doesn't do the > proper thing with the "HALT". > > What does OVMF do with bootable devices that aren't given a specific > boot order? For seabios, those devices are all on the boot list > following those with specific orders; this is what necessitates --boot > strict. The behavior of the option should be consistent regardless of > BIOS choice. Here's again how OVMF works, in detail. First, the list of openfirmware device paths is downloaded from fw_cfg. Then they are translated to UEFI device path *prefixes*. This translation (even just for the prefixes) is inexact (best effort), because no complete mapping exists. Also it can only cover UEFI device path prefixes because the OpenFirmware device paths don't extend into file paths. In UEFI you can have two separate boot options that boot two separate files from the exact same device (including partition), and you can't distinguish these in OpenFirmware device paths. Certainly not on the qemu command line. OK, so now you have two lists, the list of UEFI boot options (pre-set by the user in the firmware, or auto-generated by the firmware, doesn't matter), and the translated prefix list from qemu/fw_cfg. OVMF then iterates over the fw_cfg list, looks up the first prefix match from the UEFI boot option list that matches the current translated fw_cfg entry. If it is found, then this UEFI boot option is appended to the output list, and the UEFI boot option is also marked as having been added to the output list When the outer loop completes, you have a third list (the output list) which describes the user's boot preference. You also have some boot options that are unmarked (left unmatched by any translated fw_cfg entry). The question is what you do with these. Originally, I simply dropped these. This is precisely the -boot strict=on behavior. And it was wrong. Users wanted to keep at least *some* of these entries at the end of the list. My first question was "ok why don't you just specify those in fw_cfg?" And the answer is that those options *cannot* be specified.