11:02 a.m.
v2: Add a virt-aa-helper-test case.
dann frazier (2):
qemu: Add AAVMF32 to the list of known UEFIs
virt-aa-helper-test: Add test for aarch32 UEFI image path
src/qemu/qemu_conf.c | 12 ++++++++----
tests/virt-aa-helper-test | 1 +
2 files changed, 9 insertions(+), 4 deletions(-)
--
2.13.2
11:02 a.m.
New subject: [libvirt] [PATCH 1/2] qemu: Add AAVMF32 to the list of known UEFIs
Add a path for UEFI VMs for AArch32 VMs. This is the path Debian is
currently using in experimental. libvirt is the de facto canonical
location for where distros should place these firmware images, so let's
define this path here to try and minimize distro fragmentation.
---
src/qemu/qemu_conf.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 73c33d6788..c1bd91935b 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -130,6 +130,8 @@ void qemuDomainCmdlineDefFree(qemuDomainCmdlineDefPtr def)
#define VIR_QEMU_OVMF_SEC_NVRAM_PATH "/usr/share/OVMF/OVMF_VARS.fd"
#define VIR_QEMU_AAVMF_LOADER_PATH "/usr/share/AAVMF/AAVMF_CODE.fd"
#define VIR_QEMU_AAVMF_NVRAM_PATH "/usr/share/AAVMF/AAVMF_VARS.fd"
+#define VIR_QEMU_AAVMF32_LOADER_PATH "/usr/share/AAVMF/AAVMF32_CODE.fd"
+#define VIR_QEMU_AAVMF32_NVRAM_PATH "/usr/share/AAVMF/AAVMF32_VARS.fd"
virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged)
{
@@ -334,11 +336,11 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged)
goto error;
#else
- if (VIR_ALLOC_N(cfg->firmwares, 3) < 0)
+ if (VIR_ALLOC_N(cfg->firmwares, 4) < 0)
goto error;
- cfg->nfirmwares = 3;
+ cfg->nfirmwares = 4;
if (VIR_ALLOC(cfg->firmwares[0]) < 0 || VIR_ALLOC(cfg->firmwares[1]) < 0
||
- VIR_ALLOC(cfg->firmwares[2]) < 0)
+ VIR_ALLOC(cfg->firmwares[2]) < 0 || VIR_ALLOC(cfg->firmwares[3]) <
0)
goto error;
if (VIR_STRDUP(cfg->firmwares[0]->name, VIR_QEMU_AAVMF_LOADER_PATH) < 0 ||
@@ -346,7 +348,9 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged)
VIR_STRDUP(cfg->firmwares[1]->name, VIR_QEMU_OVMF_LOADER_PATH) < 0 ||
VIR_STRDUP(cfg->firmwares[1]->nvram, VIR_QEMU_OVMF_NVRAM_PATH) < 0 ||
VIR_STRDUP(cfg->firmwares[2]->name, VIR_QEMU_OVMF_SEC_LOADER_PATH) < 0
||
- VIR_STRDUP(cfg->firmwares[2]->nvram, VIR_QEMU_OVMF_SEC_NVRAM_PATH) < 0)
+ VIR_STRDUP(cfg->firmwares[2]->nvram, VIR_QEMU_OVMF_SEC_NVRAM_PATH) < 0
||
+ VIR_STRDUP(cfg->firmwares[3]->name, VIR_QEMU_AAVMF32_LOADER_PATH) < 0
||
+ VIR_STRDUP(cfg->firmwares[3]->nvram, VIR_QEMU_AAVMF32_NVRAM_PATH) < 0)
goto error;
#endif
--
2.13.2
1:23 p.m.
New subject: [libvirt] [PATCH 1/2] qemu: Add AAVMF32 to the list of known UEFIs
On 06/28/2017 12:02 PM, dann frazier wrote:
Add a path for UEFI VMs for AArch32 VMs. This is the path Debian is
currently using in experimental. libvirt is the de facto canonical
"experimental"?
Is this written in stone some where yet?
location for where distros should place these firmware images, so
let's
define this path here to try and minimize distro fragmentation.
hmmm... This makes it appear that nothing is decided upon yet.
---
src/qemu/qemu_conf.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
How would anyone know to use this unless qemu.conf was modified to
describe the possibility?
See commit id '436dcf0b' for when AAVMF was originally added keeping in
mind that commit id 'f2f1e388' fixed the names/path. This will give a
better idea of what additional files should be changed.
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 73c33d6788..c1bd91935b 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -130,6 +130,8 @@ void qemuDomainCmdlineDefFree(qemuDomainCmdlineDefPtr def)
#define VIR_QEMU_OVMF_SEC_NVRAM_PATH "/usr/share/OVMF/OVMF_VARS.fd"
#define VIR_QEMU_AAVMF_LOADER_PATH "/usr/share/AAVMF/AAVMF_CODE.fd"
#define VIR_QEMU_AAVMF_NVRAM_PATH "/usr/share/AAVMF/AAVMF_VARS.fd"
+#define VIR_QEMU_AAVMF32_LOADER_PATH "/usr/share/AAVMF/AAVMF32_CODE.fd"
+#define VIR_QEMU_AAVMF32_NVRAM_PATH "/usr/share/AAVMF/AAVMF32_VARS.fd"
Not that it's in my wheelhouse, but I'm somewhat surprised by the notion
to have the AAVMF directory have both 64 and 32 bit files... Guess I'm
surprised it's not AAVMF32/ since it would seem easier to be able to
have consistent names of "%s_VARS.fd" and "%s_CODE.fd" to go with the
/usr/share/%s/ path when trying to "build" a name. I've asked the
QEMU/OVMF maintainer in this space and get his insights as well.
John
virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged)
{
@@ -334,11 +336,11 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged)
goto error;
#else
- if (VIR_ALLOC_N(cfg->firmwares, 3) < 0)
+ if (VIR_ALLOC_N(cfg->firmwares, 4) < 0)
goto error;
- cfg->nfirmwares = 3;
+ cfg->nfirmwares = 4;
if (VIR_ALLOC(cfg->firmwares[0]) < 0 || VIR_ALLOC(cfg->firmwares[1]) < 0
||
- VIR_ALLOC(cfg->firmwares[2]) < 0)
+ VIR_ALLOC(cfg->firmwares[2]) < 0 || VIR_ALLOC(cfg->firmwares[3]) <
0)
goto error;
if (VIR_STRDUP(cfg->firmwares[0]->name, VIR_QEMU_AAVMF_LOADER_PATH) < 0 ||
@@ -346,7 +348,9 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged)
VIR_STRDUP(cfg->firmwares[1]->name, VIR_QEMU_OVMF_LOADER_PATH) < 0 ||
VIR_STRDUP(cfg->firmwares[1]->nvram, VIR_QEMU_OVMF_NVRAM_PATH) < 0 ||
VIR_STRDUP(cfg->firmwares[2]->name, VIR_QEMU_OVMF_SEC_LOADER_PATH) < 0
||
- VIR_STRDUP(cfg->firmwares[2]->nvram, VIR_QEMU_OVMF_SEC_NVRAM_PATH) <
0)
+ VIR_STRDUP(cfg->firmwares[2]->nvram, VIR_QEMU_OVMF_SEC_NVRAM_PATH) < 0
||
+ VIR_STRDUP(cfg->firmwares[3]->name, VIR_QEMU_AAVMF32_LOADER_PATH) < 0
||
+ VIR_STRDUP(cfg->firmwares[3]->nvram, VIR_QEMU_AAVMF32_NVRAM_PATH) < 0)
goto error;
#endif
4:07 p.m.
New subject: [libvirt] [PATCH 1/2] qemu: Add AAVMF32 to the list of known UEFIs
On Mon, Jul 10, 2017 at 12:23 PM, John Ferlan <jferlan(a)redhat.com> wrote:
On 06/28/2017 12:02 PM, dann frazier wrote:
> Add a path for UEFI VMs for AArch32 VMs. This is the path Debian is
> currently using in experimental. libvirt is the de facto canonical
"experimental"?
Hi John!
experimental is a staging archive for Debian. I uploaded it there
because Debian was in freeze at the time, not because we're continuing
to weigh options.
Is this written in stone some where yet?
I'm not sure what qualifies as stone here. I've planted a flag via
Debian, and tried to build consensus on the cross-distro list:
https://lists.linaro.org/pipermail/cross-distro/2017-April/000865.html
As you can see, mostly crickets, other than a suggestion to lock it in
via libvirt.
> location for where distros should place these firmware images, so
let's
> define this path here to try and minimize distro fragmentation.
hmmm... This makes it appear that nothing is decided upon yet.
If you know of someone else you need me to convince, point me at 'em! :)
> ---
> src/qemu/qemu_conf.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
How would anyone know to use this unless qemu.conf was modified to
describe the possibility?
See commit id '436dcf0b' for when AAVMF was originally added keeping in
mind that commit id 'f2f1e388' fixed the names/path. This will give a
better idea of what additional files should be changed.
OK, thanks - I'll take a look.
> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> index 73c33d6788..c1bd91935b 100644
> --- a/src/qemu/qemu_conf.c
> +++ b/src/qemu/qemu_conf.c
> @@ -130,6 +130,8 @@ void qemuDomainCmdlineDefFree(qemuDomainCmdlineDefPtr def)
> #define VIR_QEMU_OVMF_SEC_NVRAM_PATH "/usr/share/OVMF/OVMF_VARS.fd"
> #define VIR_QEMU_AAVMF_LOADER_PATH "/usr/share/AAVMF/AAVMF_CODE.fd"
> #define VIR_QEMU_AAVMF_NVRAM_PATH "/usr/share/AAVMF/AAVMF_VARS.fd"
> +#define VIR_QEMU_AAVMF32_LOADER_PATH "/usr/share/AAVMF/AAVMF32_CODE.fd"
> +#define VIR_QEMU_AAVMF32_NVRAM_PATH "/usr/share/AAVMF/AAVMF32_VARS.fd"
Not that it's in my wheelhouse, but I'm somewhat surprised by the notion
to have the AAVMF directory have both 64 and 32 bit files... Guess I'm
surprised it's not AAVMF32/ since it would seem easier to be able to
have consistent names of "%s_VARS.fd" and "%s_CODE.fd" to go with
the
/usr/share/%s/ path when trying to "build" a name. I've asked the
QEMU/OVMF maintainer in this space and get his insights as well.
One of my goals here is to avoid further pollution of the /usr/share
directory. I've had complaints from other Debian Developers about the
existing AAVMF and OVMF subdirs, but we've retained this for
compatibility with libvirt upstream.
-dann
11:02 a.m.
New subject: [libvirt] [PATCH 2/2] virt-aa-helper-test: Add test for aarch32 UEFI image path
Signed-off-by: dann frazier <dann.frazier(a)canonical.com>
---
tests/virt-aa-helper-test | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/virt-aa-helper-test b/tests/virt-aa-helper-test
index 51072f622c..0599046408 100755
--- a/tests/virt-aa-helper-test
+++ b/tests/virt-aa-helper-test
@@ -308,6 +308,7 @@ testme "0" "kernel" "-r -u $valid_uuid"
"$test_xml"
testfw "ovmf (old path)" "/usr/share/ovmf/OVMF.fd"
testfw "OVMF (new path)" "/usr/share/OVMF/OVMF_CODE.fd"
testfw "AAVMF" "/usr/share/AAVMF/AAVMF_CODE.fd"
+testfw "AAVMF32" "/usr/share/AAVMF/AAVMF32_CODE.fd"
testfw "qemu-efi" "/usr/share/qemu-efi/QEMU_EFI.fd"
sed -e "s,###UUID###,$uuid,g" -e "s,###DISK###,$disk1,g" -e
"s,</os>,<initrd>$tmpdir/initrd</initrd></os>,g"
"$template_xml" > "$test_xml"
--
2.13.2
2691
days inactive
2706
days old
4 comments
2 participants
participants (2)
-
dann frazier -
John Ferlan