Hi Andrea,
Thank you for your comments.
> 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.
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
