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 :|