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

Michal Privoznik mprivozn at redhat.com
Wed Dec 3 12:15:21 UTC 2014


On 02.12.2014 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, 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.
>

It is a mess, but not for libvirt. I mean, libvirt only needs to know 
the pairs of <fw_binary>:<nvram_path> so that for given firmware binary 
it knows where to copy the nvram from. Libvirt will not stop you from 
specifying AAVMF on an x86_64 guest and I don't think it should. That's 
a user problem. Or virt-install's. On the other hand, I agree that it 
should be possible to specify more than one pair at the build time.

Michal




More information about the libvir-list mailing list