On 05/09/2016 02:58 PM, Laszlo Ersek wrote: > 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. Ok, thanks good to know. > >> 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 :)) Ah, yeah I recognized him as I saw some patches on the qemu list have kraxel in the signature, awesome that he provides this as a personal service! > >> In comparison of a OVMF build from around November 2015 (I can look up >> the exact version if needed) > Could be helpful, yes.
It was: edk2.git-ovmf-x64-0-20151117.b1317.g386cdfb.noarch.rpm $ git show 386cdfb commit 386cdfbecbbacb600ffc8e2ffa8c7af1b3855a61 Author: Mark Rutland <mark.rutl...@arm.com> Date: Tue Nov 17 13:58:19 2015 +0000 So yes the BDS changes would be the effect of this, I guess. > >> 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. Ok, good to know. As I used the bootindex parameter since quite some time this should not be an affect from this change, I assume? > > * 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 Hmm, so if I specify the devices then like below (without the bogus - out of desperation - used SMM related parameter) with the bootindex flag all of them should be tried for boot, if I understand correctly? > > 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. I did not wanted to post twice here as I couldn't draw a distinct border between those question regarding my problems, but in retrospect it would be probably more helpful than throwing everything in on thread. > > 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 assumed that, thanks for confirming this assumption. >> 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. Doh, ok... This was tried in a (shamefully desperate) way to solve my issues, I read those command a little out of context and hasty in the README, Is should read and think that twice through before throwing arbitrary parameters at a problem, not good practice - thanks for noticing that and also for the explanation. > >>> -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. Ok, I sorted that out in my "qemu command generation function". > "-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. :) *shamefully looks away* > >> 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. Explains the behaviour I've seen and wondered upon. > >> 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" Ok, I had an old out of date var store deployed also, as the entries now changed a little (EFI CDROM changed to UEFI QEMU DVD-ROM, two floppys are now showing up) > > * 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. Ok, the OS did sets this up but when I start qemu without disk it starts the UEFI shell nonetheless, if I pass a disk to the VM it will always boot from this disk, still won't keep the changes which I'm making in the UEFI UI. In the shell I see the BOOTX64.EFI: ls fs0:\EFI\BOOT\BOOTX64.EFI and can add it with bcfg boot add fs0:\EFI\BOOT\BOOTX64.EFI "Test Entry" But it does not survives a reboot. So for reference, I do now the following: * VM powered down * start it with the adapted command, this time the full command without snipping in case I falsely removed some important information: > /usr/bin/systemd-run > --scope > --slice qemu > --unit 7003 > -p KillMode=none > -p CPUShares=1000 /usr/bin/kvm > -id 7003 > -chardev socket,id=qmp,path=/var/run/qemu-server/7003.qmp,server,nowait > -mon chardev=qmp,mode=control > -pidfile /var/run/qemu-server/7003.pid > -daemonize > -smbios type=1,uuid=e2e058bc-740e-4737-8430-a73959a6188b > -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/7003/vm-7003-efi.raw > -name disposable-3 > -smp 4,sockets=1,cores=4,maxcpus=4 > -nodefaults > -boot menu=on > -vga qxl > -vnc unix:/var/run/qemu-server/7003.vnc,x509,password > -cpu host,+kvm_pv_unhalt,+kvm_pv_eoi > -m 6196 > -k de > -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f > -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e > -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 > -chardev socket,path=/var/run/qemu-server/7003.qga,server,nowait,id=qga0 > -device virtio-serial,id=qga0,bus=pci.0,addr=0x8 > -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 > -spice > tls-port=61001,addr=localhost,tls-ciphers=DES-CBC3-SHA,seamless-migration=on > -device virtio-serial,id=spice,bus=pci.0,addr=0x9 > -chardev spicevmc,id=vdagent,name=vdagent > -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 > -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 > -iscsi initiator-name=iqn.1993-08.org.debian:01:468faae9322b > -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/7003/vm-7003-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 > -netdev > type=tap,id=net0,ifname=tap7003i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on > -device > virtio-net-pci,mac=62:33:37:36:38:63,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 * install the OS (a debian based one) * reboot * the VM boots the CD ISO again (bootindex says otherwise) * changing the boot order via UEFI UI does not persist (also setting resolution, for example) after set efibootmgr also shows the correct settings, /sys/firmware/efi/efivars/* is not populated after the second boot Hmm, I need to control everything again, I'm quite sure I miss something. > >> 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). The initial start and installation of the VM was without the "global driver=cfi.pflash01,property=secure,value=on" I introduced it only later on. What is a little strange is that *with* this it seems to work a little better (better is relative here), better as in the changed settings are kept when doing OS reboot or a OVMF reset. But as I learned from your explanation the reason for this would be the fallback to NvVars-on-ESP emulation, where this works somewhat but the real persistent efivars changes do not. >> I'd be glad for any help regarding this! :-) > Hope this helps, I helps really a lot, thanks for the great and detail rich explanation, I always learn a lot from your posts! btw. regarding a more auto didactic method to find answers for those question, is there something recommendable? I'd guess reading the UEFI spec and OVMF code would be helpful, the latter is - while sounding really interesting - maybe a little problematic as current university semester hasn't ended yet and work needs also a little time and I need some off time from a computer screen here and then :) (PS. If I have the luck for another answer feel free to snip) thanks, Thomas > Laszlo > > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
