[libvirt] [PATCH] spec: Advertise nvram paths of official fedora edk2 builds

Fedora now ships edk2 firmware in its official repos, so adapt the nvram path list to match. Eventually we can remove the nightly links as well once some integration kinks have been worked out, and documentation updated. Move the macro building into the %build target, which lets us build up a shell variable and make things a bit more readable https://bugzilla.redhat.com/show_bug.cgi?id=1335395 --- libvirt.spec.in | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index c7fcf85..8b88eef 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -192,12 +192,6 @@ %define qemu_group qemu -# Advertise OVMF and AAVMF from nightly firmware repo -%if 0%{?fedora} - %define arg_loader_nvram --with-loader-nvram="/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd:/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2.git/aarch64/vars-template-pflash.raw" -%endif - - %if 0%{?fedora} || 0%{?rhel} >= 7 %define with_systemd_macros 1 %else @@ -1097,6 +1091,18 @@ rm -rf .git %define arg_selinux_mount --with-selinux-mount="/selinux" %endif +%if 0%{?fedora} + # Nightly firmware repo x86/OVMF + LOADERS="/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd" + # Nightly firmware repo aarch64/AAVMF + LOADERS="$LOADERS:/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2.git/aarch64/vars-template-pflash.raw" + # Fedora official x86/OVMF + LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd" + # Fedora official aarch64/AAVMF + LOADERS="$LOADERS:/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2/aarch64/vars-template-pflash.raw" + %define arg_loader_nvram --with-loader-nvram="$LOADERS" +%endif + # place macros above and build commands below this comment %if 0%{?enable_autotools} -- 2.7.4

On Fri, 2016-05-20 at 16:03 -0400, Cole Robinson wrote:
Fedora now ships edk2 firmware in its official repos, so adapt the nvram path list to match. Eventually we can remove the nightly links as well once some integration kinks have been worked out, and documentation updated. Move the macro building into the %build target, which lets us build up a shell variable and make things a bit more readable https://bugzilla.redhat.com/show_bug.cgi?id=1335395 --- libvirt.spec.in | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index c7fcf85..8b88eef 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -192,12 +192,6 @@ %define qemu_group qemu -# Advertise OVMF and AAVMF from nightly firmware repo -%if 0%{?fedora} - %define arg_loader_nvram --with-loader-nvram="/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure- efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd:/usr/share/edk2.git/aarch64/QEMU_EFI- pflash.raw:/usr/share/edk2.git/aarch64/vars-template-pflash.raw" -%endif - - %if 0%{?fedora} || 0%{?rhel} >= 7 %define with_systemd_macros 1 %else @@ -1097,6 +1091,18 @@ rm -rf .git %define arg_selinux_mount --with-selinux-mount="/selinux" %endif +%if 0%{?fedora} + # Nightly firmware repo x86/OVMF + LOADERS="/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd" + # Nightly firmware repo aarch64/AAVMF + LOADERS="$LOADERS:/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2.git/aarch64/vars-template- pflash.raw" + # Fedora official x86/OVMF + LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd" + # Fedora official aarch64/AAVMF + LOADERS="$LOADERS:/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2/aarch64/vars-template-pflash.raw" + %define arg_loader_nvram --with-loader-nvram="$LOADERS" +%endif + # place macros above and build commands below this comment %if 0%{?enable_autotools}
I'm wondering... /etc/libvirt/qemu.conf on my Fedora contains the NVRAM paths actually used by the driver[1], but I don't see anything in our build system that would update qemu.conf to reflect the value of the --with-loader-nvram configure option. Is the file simply statically patched by Fedora? Should we come up with an upstream solution that updates the file automatically at build time? Most importantly... Why are those paths so ugly and inconsistent? :S ACK [1] There are actually two entries, only the second one has the right paths -- Andrea Bolognani Software Engineer - Virtualization Team

On 05/27/2016 12:08 PM, Andrea Bolognani wrote:
On Fri, 2016-05-20 at 16:03 -0400, Cole Robinson wrote:
Fedora now ships edk2 firmware in its official repos, so adapt the nvram path list to match. Eventually we can remove the nightly links as well once some integration kinks have been worked out, and documentation updated.
Move the macro building into the %build target, which lets us build up a shell variable and make things a bit more readable
https://bugzilla.redhat.com/show_bug.cgi?id=1335395 --- libvirt.spec.in | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in index c7fcf85..8b88eef 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -192,12 +192,6 @@ %define qemu_group qemu
-# Advertise OVMF and AAVMF from nightly firmware repo -%if 0%{?fedora} - %define arg_loader_nvram --with-loader-nvram="/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure- efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd:/usr/share/edk2.git/aarch64/QEMU_EFI- pflash.raw:/usr/share/edk2.git/aarch64/vars-template-pflash.raw" -%endif - - %if 0%{?fedora} || 0%{?rhel} >= 7 %define with_systemd_macros 1 %else @@ -1097,6 +1091,18 @@ rm -rf .git %define arg_selinux_mount --with-selinux-mount="/selinux" %endif
+%if 0%{?fedora} + # Nightly firmware repo x86/OVMF + LOADERS="/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd" + # Nightly firmware repo aarch64/AAVMF + LOADERS="$LOADERS:/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2.git/aarch64/vars-template- pflash.raw" + # Fedora official x86/OVMF + LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd" + # Fedora official aarch64/AAVMF + LOADERS="$LOADERS:/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2/aarch64/vars-template-pflash.raw" + %define arg_loader_nvram --with-loader-nvram="$LOADERS" +%endif + # place macros above and build commands below this comment
%if 0%{?enable_autotools}
I'm wondering... /etc/libvirt/qemu.conf on my Fedora contains the NVRAM paths actually used by the driver[1], but I don't see anything in our build system that would update qemu.conf to reflect the value of the --with-loader-nvram configure option. Is the file simply statically patched by Fedora? Should we come up with an upstream solution that updates the file automatically at build time?
Yeah, generating qemu.conf based on configure options is a good idea, to document how the defaults are different. It's one of the things that's kicked around in the back of my head for a long time WRT --with-qemu-user
Most importantly... Why are those paths so ugly and inconsistent? :S
The OVMF stuff is to roughly match the naming of the original RHEL packages, and with aarch64 which came later the file names were intended to be improved, but side by side it just makes things look inconsistent.
ACK
Thanks pushed now.
[1] There are actually two entries, only the second one has the right paths
Hmm, what do you mean exactly? The stock qemu.conf nvram paths match the RHEL packages, they look correct to me. - Cole

On Fri, 2016-05-27 at 12:59 -0400, Cole Robinson wrote:
Most importantly... Why are those paths so ugly and inconsistent? :S The OVMF stuff is to roughly match the naming of the original RHEL packages, and with aarch64 which came later the file names were intended to be improved, but side by side it just makes things look inconsistent.
So much for improvement! Oh well.
[1] There are actually two entries, only the second one has the right paths Hmm, what do you mean exactly? The stock qemu.conf nvram paths match the RHEL packages, they look correct to me.
Never mind, that was just me messing with the local configuration file after all :) -- Andrea Bolognani Software Engineer - Virtualization Team
participants (2)
-
Andrea Bolognani
-
Cole Robinson