So far, libvirt has assumed that only x86 supports ACPI,
but that's inaccurate since aarch64 supports it too.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
---
Advertising ACPI support in capabilities means that tools
such as virt-manager will start automatically adding the
<acpi/> element for new guests.
However, existing guests are likely to lack that element
and will suddenly lose ACPI capabilities: that could make
them unbootable if the guest OS only supports booting via
ACPI, which on the other hand is AFAIK not the case for
current mainstream OSs.
src/qemu/qemu_capabilities.c | 28 ++++++++++++++++------
.../caps_2.6.0-gicv2.aarch64.xml | 1 +
.../caps_2.6.0-gicv3.aarch64.xml | 1 +
3 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 5a3b4ac..4ec34f8 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1038,13 +1038,17 @@ virQEMUCapsInitGuestFromBinary(virCapsPtr caps,
machines = NULL;
nmachines = 0;
+ }
+ if ((ARCH_IS_X86(guestarch) || guestarch == VIR_ARCH_AARCH64) &&
+ virCapabilitiesAddGuestFeature(guest, "acpi", true, true) == NULL) {
+ goto cleanup;
}
if (ARCH_IS_X86(guestarch) &&
- (virCapabilitiesAddGuestFeature(guest, "acpi", true, true) == NULL ||
- virCapabilitiesAddGuestFeature(guest, "apic", true, false) == NULL))
+ virCapabilitiesAddGuestFeature(guest, "apic", true, false) == NULL) {
goto cleanup;
+ }
if ((guestarch == VIR_ARCH_I686) &&
(virCapabilitiesAddGuestFeature(guest, "pae", true, false) == NULL ||
@@ -4122,10 +4126,15 @@ virQEMUCapsInitHelp(virQEMUCapsPtr qemuCaps, uid_t runUid, gid_t runGid, const c
qmperr) < 0)
goto cleanup;
- /* -no-acpi is not supported on non-x86
- * even if qemu reports it in -help */
- if (!ARCH_IS_X86(qemuCaps->arch))
+ /* Older QEMU versions reported -no-acpi in the output of -help even
+ * though it was not supported by the architecture. The issue has since
+ * been fixed, but to maintain compatibility with all release we still
+ * need to filter out the capability for architectures that we know
+ * don't support the feature, eg. anything but x86 and aarch64 */
+ if (!ARCH_IS_X86(qemuCaps->arch) &&
+ qemuCaps->arch != VIR_ARCH_AARCH64) {
virQEMUCapsClear(qemuCaps, QEMU_CAPS_NO_ACPI);
+ }
/* virQEMUCapsExtractDeviceStr will only set additional caps if qemu
* understands the 0.13.0+ notion of "-device driver,". */
@@ -4222,9 +4231,14 @@ virQEMUCapsInitArchQMPBasic(virQEMUCapsPtr qemuCaps,
goto cleanup;
}
- /* ACPI/HPET/KVM PIT are x86 specific */
- if (ARCH_IS_X86(qemuCaps->arch)) {
+ /* ACPI only works on x86 and aarch64 */
+ if (ARCH_IS_X86(qemuCaps->arch) ||
+ qemuCaps->arch == VIR_ARCH_AARCH64) {
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_ACPI);
+ }
+
+ /* HPET and KVM PIT are x86 specific */
+ if (ARCH_IS_X86(qemuCaps->arch)) {
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_HPET);
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_KVM_PIT);
}
diff --git a/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml b/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml
index 0aed651..b64a6f8 100644
--- a/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml
+++ b/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml
@@ -40,6 +40,7 @@
<flag name='no-shutdown'/>
<flag name='cache-unsafe'/>
<flag name='ich9-ahci'/>
+ <flag name='no-acpi'/>
<flag name='fsdev-readonly'/>
<flag name='virtio-blk-pci.scsi'/>
<flag name='drive-copy-on-read'/>
diff --git a/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml b/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml
index 1041a12..46e368f 100644
--- a/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml
+++ b/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml
@@ -40,6 +40,7 @@
<flag name='no-shutdown'/>
<flag name='cache-unsafe'/>
<flag name='ich9-ahci'/>
+ <flag name='no-acpi'/>
<flag name='fsdev-readonly'/>
<flag name='virtio-blk-pci.scsi'/>
<flag name='drive-copy-on-read'/>
--
2.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Mar 08, 2017 at 04:56:30PM +0100, Andrea Bolognani wrote: > So far, libvirt has assumed that only x86 supports ACPI, > but that's inaccurate since aarch64 supports it too. IIUC, it only supports ACPI if using the AAVMF firmware, right ? I know that is the preferred firmware for aarch64, but IIUC it is not a hard requirement by QEMU. So even if we advertize it in the capabilities, we might need to still validate during CLI building that we're actually using AAVMF firmware. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, 2017-03-08 at 16:00 +0000, Daniel P. Berrange wrote: > > So far, libvirt has assumed that only x86 supports ACPI, > > but that's inaccurate since aarch64 supports it too. > > IIUC, it only supports ACPI if using the AAVMF firmware, right ? My current understanding is that ACPI on aarch64 requires UEFI, not necessarily AAVMF. I'll admit I haven't really considered other QEMU-compatible UEFI implementations, though, assuming they exist. Laszlo? :) > I know that is the preferred firmware for aarch64, but IIUC it is > not a hard requirement by QEMU. So even if we advertize it in the > capabilities, we might need to still validate during CLI building > that we're actually using AAVMF firmware. We currently require that ACPI is available when using UEFI, even though as mentioned above I believe it should really be the other way around. In any case, how would we validate that the pflash file we're passing to QEMU does indeed contain AAVMF? -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Mar 08, 2017 at 06:05:02PM +0100, Andrea Bolognani wrote: > On Wed, 2017-03-08 at 16:00 +0000, Daniel P. Berrange wrote: > > > So far, libvirt has assumed that only x86 supports ACPI, > > > but that's inaccurate since aarch64 supports it too. > > > > IIUC, it only supports ACPI if using the AAVMF firmware, right ? > > My current understanding is that ACPI on aarch64 requires > UEFI, not necessarily AAVMF. I'll admit I haven't really > considered other QEMU-compatible UEFI implementations, > though, assuming they exist. > > Laszlo? :) > > > I know that is the preferred firmware for aarch64, but IIUC it is > > not a hard requirement by QEMU. So even if we advertize it in the > > capabilities, we might need to still validate during CLI building > > that we're actually using AAVMF firmware. > > We currently require that ACPI is available when using UEFI, > even though as mentioned above I believe it should really > be the other way around. > > In any case, how would we validate that the pflash file > we're passing to QEMU does indeed contain AAVMF? I don't think we can, at least not right now. For the secure boot problem, we previously discussed create a standardized metadata file to accompany firmware images, which would declare what QEMU features the firmware supported. ACPI could fit into that world. It is probably time we got serious about actually doing this.... Meanwhile, we can just assume it supports ACPI. The scenario I was actually thinking of was direct kernel boot, rather than non-AAVMF impls of UEFI. IOW, where you just pass -kernel/-initrd/-dtb to QEMU and no firmware file. In that case, we should report an error if <acpi/> is requested in the XML IIUC. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 03/08/17 18:12, Daniel P. Berrange wrote: > On Wed, Mar 08, 2017 at 06:05:02PM +0100, Andrea Bolognani wrote: >> On Wed, 2017-03-08 at 16:00 +0000, Daniel P. Berrange wrote: >>>> So far, libvirt has assumed that only x86 supports ACPI, >>>> but that's inaccurate since aarch64 supports it too. >>> >>> IIUC, it only supports ACPI if using the AAVMF firmware, right ? >> >> My current understanding is that ACPI on aarch64 requires >> UEFI, not necessarily AAVMF. I'll admit I haven't really >> considered other QEMU-compatible UEFI implementations, >> though, assuming they exist. >> >> Laszlo? :) >> >>> I know that is the preferred firmware for aarch64, but IIUC it is >>> not a hard requirement by QEMU. So even if we advertize it in the >>> capabilities, we might need to still validate during CLI building >>> that we're actually using AAVMF firmware. >> >> We currently require that ACPI is available when using UEFI, >> even though as mentioned above I believe it should really >> be the other way around. >> >> In any case, how would we validate that the pflash file >> we're passing to QEMU does indeed contain AAVMF? > > I don't think we can, at least not right now. > > For the secure boot problem, we previously discussed create a standardized > metadata file to accompany firmware images, which would declare what QEMU > features the firmware supported. ACPI could fit into that world. > > It is probably time we got serious about actually doing this.... > > Meanwhile, we can just assume it supports ACPI. > > The scenario I was actually thinking of was direct kernel boot, > rather than non-AAVMF impls of UEFI. > > IOW, where you just pass -kernel/-initrd/-dtb to QEMU and no firmware > file. In that case, we should report an error if <acpi/> is requested > in the XML IIUC. Direct kernel boot without UEFI firmware should indeed conflict with <acpi/>, yes; there's no firmware to install the tables for the kernel. Direct kernel boot with UEFI firmware should permit <acpi/>. The firmware starts, does its thing (including installation of ACPI tables), then grabs the kernel from fw_cfg, and launches it. The kernel will see the tables. Thanks Laszlo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, 2017-03-08 at 18:57 +0100, Laszlo Ersek wrote: > On 03/08/17 18:12, Daniel P. Berrange wrote: > > The scenario I was actually thinking of was direct kernel boot, > > rather than non-AAVMF impls of UEFI. > > > > IOW, where you just pass -kernel/-initrd/-dtb to QEMU and no firmware > > file. In that case, we should report an error if <acpi/> is requested > > in the XML IIUC. > > Direct kernel boot without UEFI firmware should indeed conflict with > <acpi/>, yes; there's no firmware to install the tables for the kernel. > > Direct kernel boot with UEFI firmware should permit <acpi/>. The > firmware starts, does its thing (including installation of ACPI tables), > then grabs the kernel from fw_cfg, and launches it. The kernel will see > the tables. Gotcha. The non-RFC version of the series, which I just posted to the list, should handle those configurations as well. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 03/08/17 18:05, Andrea Bolognani wrote:
> On Wed, 2017-03-08 at 16:00 +0000, Daniel P. Berrange wrote:
>>> So far, libvirt has assumed that only x86 supports ACPI,
>>> but that's inaccurate since aarch64 supports it too.
>>
>> IIUC, it only supports ACPI if using the AAVMF firmware, right ?
>
> My current understanding is that ACPI on aarch64 requires
> UEFI, not necessarily AAVMF.
That's technically correct, yes. ("The best kind of correct" :))
> I'll admit I haven't really
> considered other QEMU-compatible UEFI implementations,
> though, assuming they exist.
>
> Laszlo? :)
I'm unaware of any others.
>
>> I know that is the preferred firmware for aarch64, but IIUC it is
>> not a hard requirement by QEMU. So even if we advertize it in the
>> capabilities, we might need to still validate during CLI building
>> that we're actually using AAVMF firmware.
>
> We currently require that ACPI is available when using UEFI,
> even though as mentioned above I believe it should really
> be the other way around.
For x86, the requirement looks correct. You won't find an x86 platform
that supports/exhibits UEFI but doesn't support/exhibit ACPI.
For aarch64, it's different. You can have UEFI with DT only. And, if you
see ACPI, it implies both that you have UEFI and that you are on aarch64.
>
> In any case, how would we validate that the pflash file
> we're passing to QEMU does indeed contain AAVMF?
You wouldn't. There isn't exactly a plethora of guest firmware,
especially of standardized & open source firmware. IMO equating
loader/@type == 'pflash'
with
guest uses UEFI
with
guest uses OVMF or AAVMF (as appropriate for the guest arch)
is good enough.
Laszlo
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Mar 08, 2017 at 04:56:30PM +0100, Andrea Bolognani wrote: > So far, libvirt has assumed that only x86 supports ACPI, > but that's inaccurate since aarch64 supports it too. > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509 > --- > Advertising ACPI support in capabilities means that tools > such as virt-manager will start automatically adding the > <acpi/> element for new guests. > > However, existing guests are likely to lack that element > and will suddenly lose ACPI capabilities: that could make > them unbootable if the guest OS only supports booting via > ACPI, which on the other hand is AFAIK not the case for > current mainstream OSs. Current Linux policy is to boot based on Device Tree, if both Device Tree & ACPI are advertized to the guest. If we stop advertizing ACPI for guests without <acpi/>, then QEMU would only present Device Tree, which is what any Linux guest will have already been using. So while you're right that this is a semantic change, I think it is reasonable to make this, as I expect the fallout to be minimal, and it is easy to deal with by just adding <acpi/> if it turned out to be a problem for specific guest OS types. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2026 Red Hat, Inc.