[libvirt] [PATCH v2] qemu: Allow UEFI paths to be specified at compile time
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@redhat.com> --- diff to v1: -introduce configure options too configure.ac | 22 ++++++++++++++++++++++ src/qemu/qemu.conf | 12 +++++++++--- src/qemu/qemu_conf.c | 24 ++++++++++++++++++++---- src/qemu/test_libvirtd_qemu.aug.in | 1 + 4 files changed, 52 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index 9fd44b2..c22ac75 100644 --- a/configure.ac +++ b/configure.ac @@ -2786,6 +2786,28 @@ AC_ARG_WITH([default-editor], [DEFAULT_EDITOR=vi]) AC_DEFINE_UNQUOTED([DEFAULT_EDITOR], ["$DEFAULT_EDITOR"], [Default editor to use]) +AC_ARG_WITH([default-loader], + [AS_HELP_STRING([--with-default-loader], + [Default UEFI loader path @<:@default=paths to OVMF and its clones@:>@])], + [with_default_loader=${withval}], + [with_default_loader=no]) +AC_ARG_WITH([default-nvram], + [AS_HELP_STRING([--with-default-nvram], + [Default UEFI NVRAM path @<:@default=paths to OVMF and its clones@:>@])], + [with_default_nvram=${withval}], + [with_default_nvram=no]) + +if test "$with_default_loader:$with_default_nvram" != "no:no"; then + if test "$with_default_loader" = "no"; then + AC_MSG_ERROR([Can't use nvram without loader]) + fi + if test "$with_default_nvram" = "no"; then + AC_MSG_ERROR([Can't use loader without nvram]) + fi + AC_DEFINE_UNQUOTED([DEFAULT_LOADER], ["$with_default_loader"], [Default UEFI loader]) + AC_DEFINE_UNQUOTED([DEFAULT_NVRAM], ["$with_default_nvram"], [Default UEFI nvram]) +fi + # Some GNULIB base64 symbols clash with a kerberos library AC_DEFINE_UNQUOTED([isbase64],[libvirt_gl_isbase64],[Hack to avoid symbol clash]) AC_DEFINE_UNQUOTED([base64_encode],[libvirt_gl_base64_encode],[Hack to avoid symbol clash]) diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf index c6db568..1c589a2 100644 --- a/src/qemu/qemu.conf +++ b/src/qemu/qemu.conf @@ -506,6 +506,12 @@ # however, have different variables store. Therefore the nvram is # a list of strings when a single item is in form of: # ${PATH_TO_UEFI_FW}:${PATH_TO_UEFI_VARS}. -# Later, when libvirt creates per domain variable store, this -# list is searched for the master image. -#nvram = [ "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" ] +# Later, when libvirt creates per domain variable store, this list is +# searched for the master image. The UEFI firmware can be called +# differently for different guest architectures. For instance, it's OVMF +# for x86_64 and i686, but it's AAVMF for aarch64. The libvirt default +# follows this scheme. +#nvram = [ +# "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd", +# "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd" +#] diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 4764bef..d268fc3 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -107,8 +107,10 @@ void qemuDomainCmdlineDefFree(qemuDomainCmdlineDefPtr def) VIR_FREE(def); } -#define VIR_QEMU_LOADER_FILE_PATH "/usr/share/OVMF/OVMF_CODE.fd" -#define VIR_QEMU_NVRAM_FILE_PATH "/usr/share/OVMF/OVMF_VARS.fd" +#define VIR_QEMU_OVMF_LOADER_PATH "/usr/share/AAVMF/AAVMF_CODE.fd" +#define VIR_QEMU_OVMF_NVRAM_PATH "/usr/share/AAVMF/AAVMF_VARS.fd" +#define VIR_QEMU_AAVMF_LOADER_PATH "/usr/share/OVMF/OVMF_CODE.fd" +#define VIR_QEMU_AAVMF_NVRAM_PATH "/usr/share/OVMF/OVMF_VARS.fd" virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged) { @@ -258,15 +260,29 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged) cfg->logTimestamp = true; +#if defined(DEFAULT_LOADER) && defined(DEFAULT_NVRAM) if (VIR_ALLOC_N(cfg->loader, 1) < 0 || VIR_ALLOC_N(cfg->nvram, 1) < 0) goto error; cfg->nloader = 1; - if (VIR_STRDUP(cfg->loader[0], VIR_QEMU_LOADER_FILE_PATH) < 0 || - VIR_STRDUP(cfg->nvram[0], VIR_QEMU_NVRAM_FILE_PATH) < 0) + if (VIR_STRDUP(cfg->loader[0], DEFAULT_LOADER) < 0 || + VIR_STRDUP(cfg->nvram[0], DEFAULT_NVRAM) < 0) goto error; +#else /* defined(DEFAULT_LOADER && defined(DEFAULT_NVRAM) */ + + if (VIR_ALLOC_N(cfg->loader, 2) < 0 || + VIR_ALLOC_N(cfg->nvram, 2) < 0) + goto error; + cfg->nloader = 2; + + if (VIR_STRDUP(cfg->loader[0], VIR_QEMU_OVMF_LOADER_PATH) < 0 || + VIR_STRDUP(cfg->nvram[0], VIR_QEMU_OVMF_NVRAM_PATH) < 0 || + VIR_STRDUP(cfg->loader[1], VIR_QEMU_AAVMF_LOADER_PATH) < 0 || + VIR_STRDUP(cfg->nvram[1], VIR_QEMU_AAVMF_NVRAM_PATH) < 0) + goto error; +#endif /* defined(DEFAULT_LOADER && defined(DEFAULT_NVRAM) */ return cfg; error: diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in index 30fd27e..fc4935b 100644 --- a/src/qemu/test_libvirtd_qemu.aug.in +++ b/src/qemu/test_libvirtd_qemu.aug.in @@ -76,4 +76,5 @@ module Test_libvirtd_qemu = { "log_timestamp" = "0" } { "nvram" { "1" = "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" } + { "2" = "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd" } } -- 2.0.4
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@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. 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... ccing danpb, gerd, laszlo incase anyone has further thoughts - Cole
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@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
On Tue, Dec 02, 2014 at 02:57:15PM -0500, 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@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.
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...
A directory of metadata files would work, but I think we could manage with something simpler. Just have a standard path naming convention that firmware installs should follow. eg any firmware for use with QEMU should use a dir named per the architecture it supports eg /usr/share/qemu/firmware/<arch>/<name>.{img,vars} So EDK would provide /usr/share/qemu/firmware/i686/edk2.img /usr/share/qemu/firmware/i686/edk2.vars /usr/share/qemu/firmware/x86_64/edk2.img /usr/share/qemu/firmware/x86_64/edk2.vars The AArch64 UEFI would be /usr/share/qemu/firmware/aarch64/edk2.img /usr/share/qemu/firmware/aarch64/edk2.vars The legacy SeaBIOS would be /usr/share/qemu/firmware/i686/seabios.img /usr/share/qemu/firmware/x86_64/seabios.img This makes it trivial to enumerate all the firmware images available for a particular architecture - just scan the appropriate directory for files ending in ".img". If we want to have a notion of "default" firmware, we could say that 'default.img' should be a symlink to the default firmware, probably seabios.img for the forseeable future. If you want to be really advanced you could let update-alternatives manage the default.img symlink, much as I hate update-alternatives :-) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Hi,
A directory of metadata files would work, but I think we could manage with something simpler. Just have a standard path naming convention that firmware installs should follow. eg any firmware for use with QEMU should use a dir named per the architecture it supports
eg
/usr/share/qemu/firmware/<arch>/<name>.{img,vars}
Problem #1: sometimes it's .../qemu-kvm/... Today not a problem because libvirt doesn't need to know in the first place where the qemu data directory is.
So EDK would provide
/usr/share/qemu/firmware/i686/edk2.img /usr/share/qemu/firmware/i686/edk2.vars
/usr/share/qemu/firmware/i686/seabios.img
Problem #2: How does libvirt know whenever the image is for -bios or -pflash? We could encode that in the path / filename too. While being at it we might also consider supporting non-raw formats for flash, i.e. have edk2.{code,vars}.{raw,qcow2}.
This makes it trivial to enumerate all the firmware images available for a particular architecture - just scan the appropriate directory for files ending in ".img".
I'm not convinced it is that much easier in the end. Most of the work probably is encoding the firmware list in the capabilities anyway ... Also you can't easily attach meta data like a description, or give it a nice name. On filesystem level I'd prefer keep the names simliar or identical to what the edk2 build produces, but in the gui it is probably better to present 'UEFI' instead of 'edk2' or 'ovmf' to the user. cheers, Gerd
On Wed, Dec 03, 2014 at 12:39:39PM +0100, Gerd Hoffmann wrote:
Hi,
A directory of metadata files would work, but I think we could manage with something simpler. Just have a standard path naming convention that firmware installs should follow. eg any firmware for use with QEMU should use a dir named per the architecture it supports
eg
/usr/share/qemu/firmware/<arch>/<name>.{img,vars}
Problem #1: sometimes it's .../qemu-kvm/...
Today not a problem because libvirt doesn't need to know in the first place where the qemu data directory is.
Hmm, so it occurrs to me that this is really about detecting what BIOS capabilities QEMU is able to support. We have standardized on interogating QEMU via QMP for this purpose. So rather than libvirt having to know about paths, or config files, I wonder if QEMU should own this knowledge and then expose the information via QMP. eg, libvirt can issue a 'query-bios-images' QMP command and this returns info on all installed BIOS images that QEMU can identify. QEMU can use well known filesystem paths, or it can use metadata config files, or something else. It can change this at will without impacting libvirt or other non-libvirt apps since they'd be insulated from the underlying representation by always using QMP.
So EDK would provide
/usr/share/qemu/firmware/i686/edk2.img /usr/share/qemu/firmware/i686/edk2.vars
/usr/share/qemu/firmware/i686/seabios.img
Problem #2: How does libvirt know whenever the image is for -bios or -pflash?
We could encode that in the path / filename too.
While being at it we might also consider supporting non-raw formats for flash, i.e. have edk2.{code,vars}.{raw,qcow2}.
This again makes me prefer interogating QEMU via QMP to get all the various pieces of information.
This makes it trivial to enumerate all the firmware images available for a particular architecture - just scan the appropriate directory for files ending in ".img".
I'm not convinced it is that much easier in the end. Most of the work probably is encoding the firmware list in the capabilities anyway ...
Also you can't easily attach meta data like a description, or give it a nice name. On filesystem level I'd prefer keep the names simliar or identical to what the edk2 build produces, but in the gui it is probably better to present 'UEFI' instead of 'edk2' or 'ovmf' to the user.
Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Hi,
Hmm, so it occurrs to me that this is really about detecting what BIOS capabilities QEMU is able to support.
IMHO this isn't a property of qemu, but a property of the firmware. Thats why I think the firmware packages should include some config file with the meta data.
We have standardized on interogating QEMU via QMP for this purpose. So rather than libvirt having to know about paths, or config files, I wonder if QEMU should own this knowledge and then expose the information via QMP.
We could have qemu parse the firmware config files and export this via qmp, but I fail to see the benefits this extra indirection brings us. cheers, Gerd
On Wed, Dec 03, 2014 at 01:35:18PM +0100, Gerd Hoffmann wrote:
Hi,
Hmm, so it occurrs to me that this is really about detecting what BIOS capabilities QEMU is able to support.
IMHO this isn't a property of qemu, but a property of the firmware.
Thats why I think the firmware packages should include some config file with the meta data.
It feels related to QEMU because you need to have info about whether to use -bios or -pflash, and info about the format raw vs qcow2 and whether the firmware is compatible with the particular system emulator arch.
We have standardized on interogating QEMU via QMP for this purpose. So rather than libvirt having to know about paths, or config files, I wonder if QEMU should own this knowledge and then expose the information via QMP.
We could have qemu parse the firmware config files and export this via qmp, but I fail to see the benefits this extra indirection brings us.
The location of the firmware and/or firmware config files can vary depending on what $PREFIX QEMU was installed in. I don't think that external apps should have to care about where the firmware or the firmware config files are installed - that's QEMU's build time knowledge. All an mgmt app should need to care about is the path to the QEMU binary and from that it should be able to interrogate QEMU to find out everything else and not have to hardcode any info like paths to extra assets related to QEMU. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Mi, 2014-12-03 at 12:43 +0000, Daniel P. Berrange wrote:
On Wed, Dec 03, 2014 at 01:35:18PM +0100, Gerd Hoffmann wrote:
Hi,
Hmm, so it occurrs to me that this is really about detecting what BIOS capabilities QEMU is able to support.
IMHO this isn't a property of qemu, but a property of the firmware.
Thats why I think the firmware packages should include some config file with the meta data.
It feels related to QEMU because you need to have info about whether to use -bios or -pflash,
That again depends on the firmware (whenever it wants store state in flash or not) not qemu.
and info about the format raw vs qcow2
Again depends on the firmware. -pflash accepts any blockdev, so we can use qcow2 there, which could be useful for the largely empty vars file, especially for arm where it is 64M in size.
and whether the firmware is compatible with the particular system emulator arch.
That needs to be in the firmware metadata anyway, qemu wouldn't magically know this either.
The location of the firmware and/or firmware config files can vary depending on what $PREFIX QEMU was installed in.
I don't want that. Well, the images itself should be in /usr/share/$package. But for the firmware config file I want a fixed location, not something depending on the qemu $prefix.
I don't think that external apps should have to care about where the firmware or the firmware config files are installed - that's QEMU's build time knowledge.
Firmware is *not* built together with qemu. cheers, Gerd
On Wed, Dec 03, 2014 at 02:17:48PM +0100, Gerd Hoffmann wrote:
On Mi, 2014-12-03 at 12:43 +0000, Daniel P. Berrange wrote:
On Wed, Dec 03, 2014 at 01:35:18PM +0100, Gerd Hoffmann wrote:
Hi,
Hmm, so it occurrs to me that this is really about detecting what BIOS capabilities QEMU is able to support.
IMHO this isn't a property of qemu, but a property of the firmware.
Thats why I think the firmware packages should include some config file with the meta data.
It feels related to QEMU because you need to have info about whether to use -bios or -pflash,
That again depends on the firmware (whenever it wants store state in flash or not) not qemu.
and info about the format raw vs qcow2
Again depends on the firmware. -pflash accepts any blockdev, so we can use qcow2 there, which could be useful for the largely empty vars file, especially for arm where it is 64M in size.
and whether the firmware is compatible with the particular system emulator arch.
That needs to be in the firmware metadata anyway, qemu wouldn't magically know this either.
The location of the firmware and/or firmware config files can vary depending on what $PREFIX QEMU was installed in.
I don't want that. Well, the images itself should be in /usr/share/$package. But for the firmware config file I want a fixed location, not something depending on the qemu $prefix.
I don't think that external apps should have to care about where the firmware or the firmware config files are installed - that's QEMU's build time knowledge.
Firmware is *not* built together with qemu.
It is installed together with it. eg if I do ./configure --prefix=$HOME/qemu-git && make install then all the firmware goes into $HOME/qemu-git/share/qemu. I wouldn't expect a QEMU in $HOME/qemu-git/bin/qemu-system-x86_64 to use the firmware from /usr/share Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Hi,
I don't think that external apps should have to care about where the firmware or the firmware config files are installed - that's QEMU's build time knowledge.
Firmware is *not* built together with qemu.
It is installed together with it. eg if I do
./configure --prefix=$HOME/qemu-git && make install
then all the firmware goes into $HOME/qemu-git/share/qemu.
That is only half of the story. First, there is firmware (with edk2 being the most prominent example) which is not bundled with qemu. Second, even bundled firmware is not used when distros are packaging up qemu. Instead of using the prebuilt binaries from the qemu they have separate packages for the firmware and build it from source. Today distros are using symlinks to tell qemu where the firmware is, but that scheme breaks with uefi because (a) we have multiple firmwares to choose from now and (b) we need per-vm flash storage for the efi vars. cheers, Gerd
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@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
On Wed, Dec 03, 2014 at 01:15:21PM +0100, Michal Privoznik wrote:
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@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.
If we can go the route of querying QEMU to find out a list of installed BIOS images though, then we would be able to avoid that problem in the common case. ie the x86_64 QEMU would not report the aarch64 BIOS images and vica-versa. If we report that list of BIOS images in the libvirt emulator capabilities API call then if the app/user honours that list they avoid the mis-match most of the time. Only if they completely ignore the list of reporte BIOS images and directly provide their own paths would the arch mismatch occur, and I agree that we don't need care about that Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (5)
-
Cole Robinson -
Daniel P. Berrange -
Gerd Hoffmann -
Laszlo Ersek -
Michal Privoznik