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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
