[Forwarding with Laszlo's permission - if ever you wonder whether your work on libvirt makes a difference, it does!] -------- Original Message -------- Message-ID: <528FCF54.6060203@redhat.com> Date: Fri, 22 Nov 2013 22:40:36 +0100 From: Laszlo Ersek <lersek@redhat.com> Subject: Re: [Qemu-devel] [edk2 PATCH] OvmfPkg: split the variable store to a separate file On 11/22/13 21:51, Jordan Justen wrote:

On Fri, Nov 22, 2013 at 10:43 AM, Laszlo Ersek <lersek@redhat.com> wrote:

...

OTOH building all three FDs per default might be confusing for end-users. We know for a fact that they usually don't read the README (or not thoroughly enough). If we only give them one output file per default, that's less potential for confusion.

If it will just add confusion, then perhaps it is something best left out of the README. And at that point, since splitting it is so easy, the value of having it in OVMF is debatable.

...

But I can certainly post a version where all three files are built per default, if that's what you prefer (and aren't opposed to the idea in general).

I'm not opposed to it, but I would like to wait to see what QEMU does.

OK. Let's see where the qemu patch goes (I'll have to fix the comment typo that Eric found), and if it is accepted (maybe with modifications), we can return to the OVMF patch.

Many of these scenarios were discussed in the past on qemu-devel, but a single -pflash was the only thing that stuck.

But (thanks to you) we now have a flash driver in OVMF that works *in practice*. The discussion about multiple -pflash flags is not academic any longer. (Hm, sorry, that's maybe too strong -- I can't really say if the discussion used to be academic before. But it cannot have been this practical.) We also know that the libvirt developers prefer the split file. Plus:

This has made me just focus on making the single file pflash work. You also can't deny that the QEMU command line gets ugly real fast.

We're in violent agreement on that -- which emphasizes the need for good libvirt support all the more. Seriously, I refuse to work with the qemu command line day to day. I have an elaborate wrapper script that I insert between qemu and libvirt (specified in the <emulator> libvirt domain XML) that post-processes the arguments composed by libvirt. I need this to test out features that libvirt doesn't yet support. For example, I can set various filenames in the <loader> element -- it specifies the argument to the -bios option. In the script I check the argument against various patterns, and I can turn it into: - -bios "$ARG" - -pflash "$ARG" - -pflash "$ARG" -pflash "$(manipulate "$ARG")" The script handles CSM vs. pure-UEFI for Windows 2008, it can honor upstream vs. RHEL qemu differences, it can turn off the iPXE virtio-net driver. In the single -pflash option case, it does refresh the code part in the VM's copy of OVMF (with dd) from my most recent build. It sets a name-dependent output file for the debug port. Etc. Maintaining this script over months has paid off orders of magnitude better than working with the raw qemu command line would have. (I can compare: on my (occasionally used) AMD desktop that runs Debian I have not bothered to install libvirt, and each time I need to modify the forty line qemu command that I keep in a script file, I cringe. And I can't bring myself to install a second guest.) The convenience/efficiency libvirt gives me is critical. Changing boot order, adding or removing devices, starting & stopping -- these are very fast in virt-manager. Editing the configuration with virsh is nice (and it has some level of automatic verification when you save and exit). Comparing guest configs against each other (using the XMLs) is very convenient. And so on. I depend on these every day, but I need to modify the wrapper script only occasionally. Libvirt still allows me to send custom monitor commands, and I can set it to log all of its *own* commands that it sends to the monitor or the guest agent. I've always wondered how other developers (for example, you :)) can exist without libvirt at all! That is why "keep the qemu command line simple" (== approx. "two -pflash options are inconvenient") is no concern of mine. That ship has sailed. Thanks, Laszlo