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