Question about error conditions for ACPI usage on aarch64
Hi all, We are currently working on CCA support. Due to CCA specifications, we are unable to use pflash with QEMU. Therefore, we intend to enable ACPI by specifying the UEFI firmware using the QEMU -bios option as follows: -machine virt,acpi=on -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd Using the above QEMU option, we can successfully boot VM. My understanding is that the above QEMU option could be translated by the following libvirt XML: <os> <type arch='aarch64' machine='virt-4.0'>hvm</type> <loader type="rom">/usr/share/qemu-efi-aarch64/QEMU_EFI.fd</loader> </os> <features> <acpi/> </features> However, this XML configuration results in a validation error. Specifically, the error occurs because def->os.firmware is VIR_DOMAIN_OS_DEF_FIRMWARE_NONE during the following check: src/qemu/qemu_validate.c: qemuValidateDomainDef() /* On aarch64, ACPI requires UEFI */ if (def->features[VIR_DOMAIN_FEATURE_ACPI] == VIR_TRISTATE_SWITCH_ON && def->os.arch == VIR_ARCH_AARCH64 && (def->os.firmware != VIR_DOMAIN_OS_DEF_FIRMWARE_EFI && !virDomainDefHasOldStyleUEFI(def))) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("ACPI requires UEFI on this architecture")); return -1; } It appears that a configuration that successfully boots QEMU directly is being rejected by libvirt. Could you please explain if there's a specific reason for this strict validation? We are particularly interested in why VIR_DOMAIN_OS_DEF_FIRMWARE_NONE also becomes a condition for this error. Best Regards, Kazuhiro Abe
On Thu, Nov 06, 2025 at 02:38:28AM +0000, Kazuhiro Abe (Fujitsu) via Devel wrote:
Hi all,
We are currently working on CCA support. Due to CCA specifications, we are unable to use pflash with QEMU. Therefore, we intend to enable ACPI by specifying the UEFI firmware using the QEMU -bios option as follows:
-machine virt,acpi=on -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd
Using the above QEMU option, we can successfully boot VM. My understanding is that the above QEMU option could be translated by the following libvirt XML:
<os> <type arch='aarch64' machine='virt-4.0'>hvm</type> <loader type="rom">/usr/share/qemu-efi-aarch64/QEMU_EFI.fd</loader> </os> <features> <acpi/> </features>
However, this XML configuration results in a validation error. Specifically, the error occurs because def->os.firmware is VIR_DOMAIN_OS_DEF_FIRMWARE_NONE during the following check:
src/qemu/qemu_validate.c: qemuValidateDomainDef()
/* On aarch64, ACPI requires UEFI */ if (def->features[VIR_DOMAIN_FEATURE_ACPI] == VIR_TRISTATE_SWITCH_ON && def->os.arch == VIR_ARCH_AARCH64 && (def->os.firmware != VIR_DOMAIN_OS_DEF_FIRMWARE_EFI && !virDomainDefHasOldStyleUEFI(def))) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("ACPI requires UEFI on this architecture")); return -1; }
It appears that a configuration that successfully boots QEMU directly is being rejected by libvirt.
Could you please explain if there's a specific reason for this strict validation? We are particularly interested in why VIR_DOMAIN_OS_DEF_FIRMWARE_NONE also becomes a condition for this error.
Historically this scenario was not supported, so libvirt blocked it to give better error diagnose of configuration mistakes. If CCA needs this configuration, the qemu_validate.c check should simply be changed to allow the required config. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Hi Daniel, Thanks for your comment.
On Thu, Nov 06, 2025 at 02:38:28AM +0000, Kazuhiro Abe (Fujitsu) via Devel wrote:
Hi all,
We are currently working on CCA support. Due to CCA specifications, we are unable to use pflash with QEMU. Therefore, we intend to enable ACPI by specifying the UEFI firmware using the QEMU -bios option as follows:
-machine virt,acpi=on -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd
Using the above QEMU option, we can successfully boot VM. My understanding is that the above QEMU option could be translated by the following libvirt XML:
<os> <type arch='aarch64' machine='virt-4.0'>hvm</type> <loader type="rom">/usr/share/qemu-efi-aarch64/QEMU_EFI.fd</loader> </os> <features> <acpi/> </features>
However, this XML configuration results in a validation error. Specifically, the error occurs because def->os.firmware is VIR_DOMAIN_OS_DEF_FIRMWARE_NONE during the following check:
src/qemu/qemu_validate.c: qemuValidateDomainDef()
/* On aarch64, ACPI requires UEFI */ if (def->features[VIR_DOMAIN_FEATURE_ACPI] == VIR_TRISTATE_SWITCH_ON && def->os.arch == VIR_ARCH_AARCH64 && (def->os.firmware != VIR_DOMAIN_OS_DEF_FIRMWARE_EFI && !virDomainDefHasOldStyleUEFI(def))) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("ACPI requires UEFI on this architecture")); return -1; }
It appears that a configuration that successfully boots QEMU directly is being rejected by libvirt.
Could you please explain if there's a specific reason for this strict validation? We are particularly interested in why VIR_DOMAIN_OS_DEF_FIRMWARE_NONE also becomes a condition for this error.
Historically this scenario was not supported, so libvirt blocked it to give better error diagnose of configuration mistakes.
If CCA needs this configuration, the qemu_validate.c check should simply be changed to allow the required config.
Understood. Since CCA needs this configuration, I will submit a patch to allow the required config. Best Regards, Kazuhiro Abe
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Wed, Nov 12, 2025 at 08:05:46AM +0000, Kazuhiro Abe (Fujitsu) via Devel wrote:
On Thu, Nov 06, 2025 at 02:38:28AM +0000, Kazuhiro Abe (Fujitsu) via Devel wrote:
Hi all,
We are currently working on CCA support. Due to CCA specifications, we are unable to use pflash with QEMU. Therefore, we intend to enable ACPI by specifying the UEFI firmware using the QEMU -bios option as follows:
-machine virt,acpi=on -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd
Using the above QEMU option, we can successfully boot VM. My understanding is that the above QEMU option could be translated by the following libvirt XML:
<os> <type arch='aarch64' machine='virt-4.0'>hvm</type> <loader type="rom">/usr/share/qemu-efi-aarch64/QEMU_EFI.fd</loader> </os> <features> <acpi/> </features>
However, this XML configuration results in a validation error. Specifically, the error occurs because def->os.firmware is VIR_DOMAIN_OS_DEF_FIRMWARE_NONE during the following check:
src/qemu/qemu_validate.c: qemuValidateDomainDef()
/* On aarch64, ACPI requires UEFI */ if (def->features[VIR_DOMAIN_FEATURE_ACPI] == VIR_TRISTATE_SWITCH_ON && def->os.arch == VIR_ARCH_AARCH64 && (def->os.firmware != VIR_DOMAIN_OS_DEF_FIRMWARE_EFI && !virDomainDefHasOldStyleUEFI(def))) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("ACPI requires UEFI on this architecture")); return -1; }
It appears that a configuration that successfully boots QEMU directly is being rejected by libvirt.
Could you please explain if there's a specific reason for this strict validation? We are particularly interested in why VIR_DOMAIN_OS_DEF_FIRMWARE_NONE also becomes a condition for this error.
Historically this scenario was not supported, so libvirt blocked it to give better error diagnose of configuration mistakes.
If CCA needs this configuration, the qemu_validate.c check should simply be changed to allow the required config.
Understood. Since CCA needs this configuration, I will submit a patch to allow the required config.
To clarify, the dependency on UEFI for ACPI is correct, at least to the best of my knowledge. The problem is that libvirt doesn't realize that edk2 loaded via -bios is still UEFI, so the check fails. For this specific case, it would probably be enough to ensure that the edk2 package installs a firmware descriptor along the lines of { "interface-types": [ "uefi" ], "mapping": { "device": "memory", "filename": "/usr/share/qemu-efi-aarch64/QEMU_EFI.fd" }, "targets": [ { "architecture": "aarch64", "machines": [ "virt-*" ] } ] } This should allow libvirt to automatically set <os firmware='efi'>, at which point the check will pass. This is exactly what happens for e.g. the SEV-SNP firmware builds. Note that I haven't actually tried the above, so there might be other lingering issues that I'm not aware of. I am currently working on some changes of my own in the area in order to enable the uefi-vars QEMU devices, which also expect edk2 to be loaded via -bios; so if there is anything else missing, I expect that I will run into it and fix it shortly. -- Andrea Bolognani / Red Hat / Virtualization
Hi Andrea, Thank you for your comments.
On Thu, Nov 06, 2025 at 02:38:28AM +0000, Kazuhiro Abe (Fujitsu) via Devel wrote:
Hi all,
We are currently working on CCA support. Due to CCA specifications, we are unable to use pflash with QEMU. Therefore, we intend to enable ACPI by specifying the UEFI firmware using the QEMU -bios option as follows:
-machine virt,acpi=on -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd
Using the above QEMU option, we can successfully boot VM. My understanding is that the above QEMU option could be translated by the following libvirt XML:
<os> <type arch='aarch64' machine='virt-4.0'>hvm</type> <loader type="rom">/usr/share/qemu-efi-aarch64/QEMU_EFI.fd</loader> </os> <features> <acpi/> </features>
However, this XML configuration results in a validation error. Specifically, the error occurs because def->os.firmware is VIR_DOMAIN_OS_DEF_FIRMWARE_NONE during the following check:
src/qemu/qemu_validate.c: qemuValidateDomainDef()
/* On aarch64, ACPI requires UEFI */ if (def->features[VIR_DOMAIN_FEATURE_ACPI] == VIR_TRISTATE_SWITCH_ON && def->os.arch == VIR_ARCH_AARCH64 && (def->os.firmware != VIR_DOMAIN_OS_DEF_FIRMWARE_EFI && !virDomainDefHasOldStyleUEFI(def))) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("ACPI requires UEFI on this architecture")); return -1; }
It appears that a configuration that successfully boots QEMU directly is being rejected by libvirt.
Could you please explain if there's a specific reason for this strict validation? We are particularly interested in why VIR_DOMAIN_OS_DEF_FIRMWARE_NONE also becomes a condition for
On Wed, Nov 12, 2025 at 08:05:46AM +0000, Kazuhiro Abe (Fujitsu) via Devel wrote: this error.
Historically this scenario was not supported, so libvirt blocked it to give better error diagnose of configuration mistakes.
If CCA needs this configuration, the qemu_validate.c check should simply be changed to allow the required config.
Understood. Since CCA needs this configuration, I will submit a patch to allow the required config.
To clarify, the dependency on UEFI for ACPI is correct, at least to the best of my knowledge. The problem is that libvirt doesn't realize that edk2 loaded via -bios is still UEFI, so the check fails.
For this specific case, it would probably be enough to ensure that the edk2 package installs a firmware descriptor along the lines of
{ "interface-types": [ "uefi" ], "mapping": { "device": "memory", "filename": "/usr/share/qemu-efi-aarch64/QEMU_EFI.fd" }, "targets": [ { "architecture": "aarch64", "machines": [ "virt-*" ] } ] }
This should allow libvirt to automatically set <os firmware='efi'>, at which point the check will pass. This is exactly what happens for e.g. the SEV-SNP firmware builds.
Note that I haven't actually tried the above, so there might be other lingering issues that I'm not aware of. I am currently working on some changes of my own in the area in order to enable the uefi-vars QEMU devices, which also expect edk2 to be loaded via -bios; so if there is anything else missing, I expect that I will run into it and fix it shortly.
I understand your suggested approach. My understanding is that this is the case where autoselection is enabled and the JSON file in /usr/share/qemu/firmware is referenced. In a CCA environment, I think the common approach is to enable autoselection and reference the JSON file in /usr/share/qemu/firmware. However, there are cases where autoselection is disabled, such as when using <os> <loader type='rom'>, the JSON file will not be referenced. In such scenarios, your proposed method fails to allow libvirt to automatically set <os firmware='efi'>, and the issue still persists. Therefore, we plan to submit a patch to fix the ACPI error conditions, aiming for a more fundamental solution. Best Regards, Kazuhiro Abe
-- Andrea Bolognani / Red Hat / Virtualization
On Tue, Nov 18, 2025 at 02:37:57AM +0000, Kazuhiro Abe (Fujitsu) wrote:
To clarify, the dependency on UEFI for ACPI is correct, at least to the best of my knowledge. The problem is that libvirt doesn't realize that edk2 loaded via -bios is still UEFI, so the check fails.
For this specific case, it would probably be enough to ensure that the edk2 package installs a firmware descriptor along the lines of
{ "interface-types": [ "uefi" ], "mapping": { "device": "memory", "filename": "/usr/share/qemu-efi-aarch64/QEMU_EFI.fd" }, "targets": [ { "architecture": "aarch64", "machines": [ "virt-*" ] } ] }
This should allow libvirt to automatically set <os firmware='efi'>, at which point the check will pass. This is exactly what happens for e.g. the SEV-SNP firmware builds.
Note that I haven't actually tried the above, so there might be other lingering issues that I'm not aware of. I am currently working on some changes of my own in the area in order to enable the uefi-vars QEMU devices, which also expect edk2 to be loaded via -bios; so if there is anything else missing, I expect that I will run into it and fix it shortly.
I understand your suggested approach. My understanding is that this is the case where autoselection is enabled and the JSON file in /usr/share/qemu/firmware is referenced.
In a CCA environment, I think the common approach is to enable autoselection and reference the JSON file in /usr/share/qemu/firmware. However, there are cases where autoselection is disabled, such as when using <os> <loader type='rom'>, the JSON file will not be referenced. In such scenarios, your proposed method fails to allow libvirt to automatically set <os firmware='efi'>, and the issue still persists.
You've just identified one of those issues that I predicted I would run into and have to fix :) I already have a patch addressing that, among other things, in my local branch. I expect to be able to post the whole series shortly, probably next week. -- Andrea Bolognani / Red Hat / Virtualization
participants (3)
-
Andrea Bolognani -
Daniel P. Berrangé -
Kazuhiro Abe (Fujitsu)