[libvirt] [PATCH v2] qemu: Allow UEFI paths to be specified at compile time

[Laszlo Ersek]

On 12/02/14 20:57, Cole Robinson wrote:
> On 12/02/2014 07:51 AM, Michal Privoznik wrote:
>> Up until now there are just two ways how to specify UEFI paths to
>> libvirt. The first one is editing qemu.conf, the other is editing
>> qemu_conf.c and recompile. Therefore, two new configure options
>> are invented: --with-default-loader --with-default-nvram.
>>
>> At the same time, the list of default paths is extended to AAVMF.
>> which is an aarch64 port of OVMF.
>>
>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>> ---
>>
>> diff to v1:
>> -introduce configure options too
>>
> 
> Hmm, I'm not sure if just allowing one pair at compile time is sufficient.
> 
> While RHEL only cares about KVM, which means host arch == guest arch, in
> Fedora we want to facilitate aarch64 VMs on x86. So we want to teach
> libvirt about an x86 uefi->vars mapping as well as an aarch64 uefi->vars
> mapping regardless of the host arch.
> 
> But even if both are tracked, things would still be suboptimal for tools
> since we don't know what binaries are expected for what VM arch without
> scraping file names. Maybe domcapabilities could report architecture as
> well,

If I remember correctly, a third field was considered at some point for
the nvram element type. Firmware binary, varstore template, and (as 3rd
field) guest architecture.

I felt that such a third field was both insufficient and unnecessary.

Insufficient because even if you filter the list for the guest arch that
the user wants, you might end up with several options:
- below you mention CSM vs. pure-UEFI build, correctly;
- there's also "secure boot enabled build" vs. "secure boot disabled
  build" (where those binaries also need different variable store
  templates, even on the same architecture),
- some ad-hoc builds,
- etc.

Therefore, my thinking went, you can't avoid presenting the user with a
list of firmwares to pick from anyway, and that dialog then makes the
filtering & any further fields in "nvram" unnecessary. Let the user
worry about picking a firmware that he likes, covering architecture and
all other aspects.

Of course when I had the above thoughts I didn't know yet that you abhor
the nuts n' bolts approach... :)

> but there's no way to make that distinction with this configure
> option. This situation is kind of a mess, and even messier if anyone
> wanted to advertise even more uefi options like csm for example.
> 
> Gerd's idea of a firmware.d directory, where packages would drop config
> files describing their pairs with extra metadata like a description,
> associated arch, etc:
> 
> https://www.redhat.com/archives/virt-tools-list/2014-September/msg00145.html
> 
> 
> That allows keeping all the relevant data contained with firmware
> packages, and we could make libvirt automatically pick up mappings when
> a new package is installed, expose them via
> capabilities/domcapabilities, etc. But it's a decent chunk of work...

Probably.

It still wouldn't save you from asking the user about his firmware
preference. (The "CSM/pure-UEFI, secure boot enabled/disabled,
distro-shipped / 3rd party build" decision would still need to be made
at guest creation time.)

IMO picking a firmware (a binary with its associated varstore template)
is not much different from picking an installer ISO. If you pick an
installer ISO for the wrong guest architecture (like an x86_64 Fedora
LiveCD for an aarch64 guest), it won't boot. Which means that the user
*already* needs to be aware of mixing & matching guest architectures.

I think the same approach should work for firmware images as well. Let
the user worry about it.

Thanks
Laszlo

> ccing danpb, gerd, laszlo incase anyone has further thoughts
> 
> - Cole