On 03/22/17 10:00, Huttunen, Janne (Nokia - FI/Espoo) wrote: > On Wed, 2017-03-22 at 04:43 -0400, Paolo Bonzini wrote: >> >> Understood---my question is how you would set up the alternate >> boot order: is it something like "keep a button pressed while >> turning on", or something written in NVRAM, or something else >> that is completely different? > > In my case the real hardware has a management processor > on the board and the temporary boot source (and also the > permanent one for that matter) for the main processor can > be set from there. Since neither the BIOS nor the management > firmware are open source, I don't know how it technically > works, but I assume there either is some shared memory > between the main BIOS and the management processor or > alternatively the BIOS talks with the management processor > with some protocol during boot to get the order. >
I'm generally opposed to the proposed implementation for this feature / use case; that is, the new "bootonceindex" device property. (1) My somewhat hand-waving counter-argument is simply the complexity / confusion that it introduces. See for example recent QEMU commit c0d9f7d0bced ("docs: Add a note about mixing bootindex with "-boot order"", 2017-02-28). Even if the proposed solution keeps the "bootorder" fw_cfg file intact, and firmware wouldn't have to look at other fw_cfg files -- I can already guarantee that OVMF will not look at other fw_cfg files --, the command line changes look undesirable to me. (2) My more technical counter-arguments are: (2a) Exposing this in the libvirt domain XML would be a huge pain. AFAICS, libvirt already doesn't expose "-boot once" in the domain XML, which is a *good* thing. (2b) With the proposed change, "having rebooted once" becomes explicit runtime state that is guest-controlled. As such, it would have to be migrated. Assume that you start the guest on the source host, using both bootindex and bootonceindex properties. Then, for migration, libvirt (or the user, manually) starts QEMU on the target host using the same command line. After migration, if the guest reboots on the target host, its behavior should depend on whether said reboot is its first reboot since launching the domain, so the fact whether it rebooted on the source host should reach the target host. I think you must already have a means to massage the management processor to change the boot order, for the next boot. Are you doing that massaging in code that runs on the main processor? If so, that means the "guest code" is highly privileged, as it can control outside components in order to influence the boot order. For that, I can offer the following analogy: - use a guest with libvirt - whenever you want to modify the boot order from within the guest, ssh back out to the host, and use virsh-dumpxml (--inactive), the xmlstarlet utility, and virsh-define, to dump, edit, and save the domain XML non-interactively. Xmlstarlet is extremely versatile for modifying domain XMLs (or any other kinds of XMLs), and virsh-define explicitly supports the case when the domain is already running. In a normal virtualization environment, this would be a huge security hole, of course, but you are already manipulating the management processor from code that runs on the main processor. Exact same privilege escalation. - whenever you want to relaunch the domain fully (i.e., restart QEMU with a new command line), again ssh out to the host, and start a process (a shell script) in the background. The script should first initiate a domain shutdown (virsh-shutdown), then wait for domain termination (virsh-qemu-monitor-event, and see the SHUTDOWN event in "qapi/event.json"), then start the domain (virsh start). Which is when the modified boot order will take effect. Alternatively, if you are fine using OVMF (as UEFI firmware) within the guest, to run your payload, you can try the following commands, to set the BootNext UEFI variable & to reboot: efibootmgr --bootnext XXXX reboot While OVMF heavily massages the UEFI boot order (based on the "bootorder" fw_cfg file), *if* you stick with a constant set of bootindex properties (== constant boot order setting in the libvirt domain XML), then most of the UEFI BootXXXX variables that you get to see in the guest *should* be stable, and the above commands should hopefully work (no guarantees though). Thanks Laszlo