On 05/09/16 13:39, Thomas Lamprecht wrote: > Hi, > > This message would probably better fit on a user list, but as there > isn't any AFAIK, so I post it here, if there is a better place for this > I would be glad if someone could point that out.
I think this list is fine. Especially because any OVMF query might turn out as related to a general / core edk2 module, and then other maintainers can chime in. > I'm playing with actual versions of OVMF build straight from git, also > tested with the one from kraxel.org's Jenkins CI builds (much thanks to > the one who provides them!!) Those are provided by my colleague Gerd Hoffmann, as a personal service (not related to Red Hat). If you want to email him, you can easily find his email address(es) from his patches around the net. (His name is directly available from the whois information for kraxel.org, so I'm not unveiling a huge secret here :)) > In comparison of a OVMF build from around November 2015 (I can look up > the exact version if needed) Could be helpful, yes. > I caught a few changes regarding the boot > order and its settings. > > Is it by design that not all devices listed in the boot order section > get probed (anymore)? > E.g. it tries only EFI CD/ROM which is the first by default and then > gives up printing an error and after an timeout I get the UEFI shell. > If I open the UEFI settings and directly choose "EFI Misc Device" I get > the working grub2 of my VM, but this was not needed in the earlier > version, there it probed all devices until something "bootable" found > and only if all were tried it did throw an error. > > Am I'm missing something here, or using it incorrect? I think you may be encountering a change where it is out of scope for OVMF to ensure stability. (You can try to build OVMF with -D USE_OLD_BDS to see if the IntelFrameworkModulePkg BDS is whose behavior you are missing.) There are two things to consider when talking about the boot order. The first is the generic BDS library from edk2 that OVMF uses to enumerate all possible boot options. The second is the boot option filtering and reordering that OVMF does itself, staring out from the full enumeration. * Regarding the first part, the BDS library (and the related BDS driver), OVMF has been very recently migrated from the IntelFrameworkModulePkg BDS to the new core BDS, under MdeModulePkg. See <https://github.com/tianocore/edk2/issues/62>. Setting -D USE_OLD_BDS allows users to turn off this change (temporarily -- we'll soon remove the fallback). The reason for the new BDS infrastructure is that it follows the UEFI spec much more closely, and that it separates out UI and BDS driver responsibilities to separate modules. * Regarding the second part, OVMF consults the "bootorder" firmware config file from QEMU, translates it to UEFI boot option fragments, and reorders and filters the fully enumerated boot option list (from the previous step) against it. Given that some UEFI boot options (that are auto-generated and useful, like the UEFI shell) are not expressible by QEMU in the "bootorder" firmware config file, OVMF preserves such UEFI boot options at the end of the boot order. The observable behavior is that: - what you pass in the "bootorder" fw_cfg file, will be tried for booting, in the order that you passed it in, - what you do not pass, *although you could* (because QEMU could express it), will not be booted, - what you do not pass (because QEMU cannot express it), will be preserved at the end of the boot order list, in some unspecified order. If you don't pass a "bootorder" fw_cfg file at all, then the first two items fall away, and only the last item takes effect. I suspect that the boot order change you are witnessing is due to that "unspecified order", in the last item. The auto-generation of boot options (by the generic BDS library) keeps preexistent boot options at the beginning of the full set, and adds new ones at the end, but the order of "new ones" at the end may have changed, due to the patches for issue #62. Again, keeping this order "stable" (as far as item #3 on the above list is concerned) is out of scope for OVMF. If you want a stable boot order, you must instruct QEMU to expose the "boorder" fw_cfg file to OVMF. On the QEMU command line, this is possible by adding the "bootindex=N" property to the "-device XXXX" options. For example, -device virtio-blk-pci,...,bootindex=2 In the libvirt domain XML, it is possible by adding the following element to disk, network, assigned device (= hostdev) etc elements: <boot order='N'/> > Also this behaviour wouldn't be a slight nuisance if I could get the > efivars store permanent, so that I could save the boot order. That's a separate (albeit overlapping) question. While you should *definitely* use permanent, i.e., pflash, backing for your varstore (and it should be a separate pflash chip from the read-only one that supplies the firmware executable), the boot order manipulation above is independent of it. > I'm using this command to launch OVMF (I stripped it a little down for > readability, removed spice/vnc sockets and devices): > >> /usr/bin/kvm -id 7001 >> -chardev >> socket,id=qmp,path=/var/run/qemu-server/7001.qmp,server,nowait -mon >> chardev=qmp,mode=control >> -pidfile /var/run/qemu-server/7001.pid >> -smbios type=1,uuid=a570abd4-c963-47da-a376-1eff898a1a70 >> -global driver=cfi.pflash01,property=secure,value=on >> -drive >> if=pflash,format=raw,unit=0,readonly,file=/usr/share/kvm/OVMF-pure-efi.fd >> -drive >> if=pflash,format=raw,unit=1,file=/var/lib/vz/images/7001/vm-7001-efi.raw Ouch. :) Thus far we have both good options and bad options. The good options are the two "-drive if=pflash,..." ones. You are correctly using two separate plash chips; one is read-only and host-global, supplying the firmware binary; the other one is read-write, and backs the private varstore for the VM. Great. However: "OVMF-pure-efi.fd" is an OVMF binary that *lacks* the SMM driver stack. It does not have -D SMM_REQUIRE. But, a bit higher up, you pass -global driver=cfi.pflash01,property=secure,value=on which is completely bogus for an OVMF build that has no SMM. Where do you take this setting from? In the OvmfPkg/README file, this setting is documented in the "SMM support" section. Without SMM support, this setting will make your pflash chip effectively read-only, and cause OVMF to fall back to the antique, NvVars-on-ESP emulation. Big no no. >> -name disposable-1 >> -smp 4,sockets=1,cores=4,maxcpus=4 >> -nodefaults >> -boot menu=on,strict=on,reboot-timeout=1000 For OVMF, "-boot strict=on" makes no difference. "-boot reboot-timeout=nnn" is also useless. "-boot menu=on" does makes sense. It gives the user three seconds (or a different amount of milliseconds, specified with ",splash-time=N") to enter the setup TUI during boot. >> -vga qxl >> -cpu host,+kvm_pv_unhalt,+kvm_pv_eoi >> -m 6196 -k de -readconfig /usr/share/qemu-server/pve-q35.cfg >> -chardev socket,path=/var/run/qemu-server/7001.qga,server,nowait,id=qga0 >> -drive if=none,id=drive-ide2,media=cdrom,aio=threads -device >> ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 >> -drive >> file=/var/lib/vz/images/7001/vm-7001-disk-1.qcow2,if=none,id=drive-virtio0,format=qcow2,cache=none,aio=native,detect-zeroes=on >> -device >> virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 Right, you have two "-device XXX,bootindex=N" options. Looks correct. > With this /var/lib/vz/images/7001/vm-7001-efi.raw never gets > changed/written Of course. The option I mentioned above, -global driver=cfi.pflash01,property=secure,value=on instructs QEMU to restrict writes into the (writeable) pflash chip to SMM context only. Since your OVMF build includes no SMM driver stack, OVMF never runs in SMM, and the pflash chip appears read-only to the (non-SMM) flash driver. Then OVMF falls back to the NvVars-on-ESP emulation. So, this is self-inflicted. :) > and any settings I make won't survive a reboot, or > better the survive a reboot but no (graceful) poweroff - power on cycle. Exactly -- that is why the NvVars-on-ESP emulation was always broken, in non-intuitive ways: when you change UEFI variables from OS runtime, then gracefully power off the virtual machine without rebooting, the firmware never re-acquires exclusive access to the EFI System Partition, and cannot flush in-memory changes to the NvVars file. > I checked the OVMF README from git and tried a few possibilities, e.g. > at first I did not used "-global > driver=cfi.pflash01,property=secure,value=on" > or did not used the "unit=X" [X = (0,1)] in the pflash drives. Your varstore is likely busted (or completely empty) at this point. The proper way to go ahead is: * power down the VM * recreate the "vm-7001-efi.raw" file afresh, from the varstore template "/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd" * drop the global cfi.pflash01 property in question, from the QEMU command line * boot your VM * dependent on your guest OS, it may have installed a utility on your ESP, under the name \EFI\BOOT\BOOTX64.EFI, that recreates a good boot option for you. If there is no such utility (under this name) on your ESP, then you will have to interrupt the OVMF boot process, add the correct boot option manually, and move it to the top of the boot order. > I'm using Qemu 2.5 and checked also occasionally tested with 2.6 (rc1-3). > > I tried skimming through the commits but this repo is really active, > that in combination that I'm not quite able to just understand all > commits lead to nothing found out if/where there were changes made > regarding the boot order/probing. > > For the persistence efivars problem I'm quite sure I miss something and > the problem is me using it wrong... Right, option -global driver=cfi.pflash01,property=secure,value=on is bogus. I do understand that you tried to invoke QEMU without this option, and saw no improvements. However, assuming you installed the guest OS with this option in place to begin with, the boot option that the OS installer created had surely never reached the right storage (the varstore pflash chip). > I'd be glad for any help regarding this! :-) Hope this helps, Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
