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