[libvirt] [PATCH] qemu: Support OVMF on aarch64 guests

[Laszlo Ersek]

On 11/19/14 18:02, Daniel P. Berrange wrote:
> On Wed, Nov 19, 2014 at 05:57:24PM +0100, Laszlo Ersek wrote:
>> On 11/19/14 17:46, Daniel P. Berrange wrote:

>>> This arch check for OVMF is an arbitrary check placed in libvirt
>>> code which is not related to the current QEMU binary in any way.
>>
>> It communicates what we had looked at and had determined to work. I
>> preferred not to enable targets that (a) had been known not to work with
>> UEFI, (b) had not been known to work or not with UEFI.
>>
>> At that time noone knew that (1) edk2's ArmVirtualizationQemu platform
>> would be born soon (in other words, a UEFI binary for
>> 'qemu-system-aarch64 -M virt' would be implemented soon), (2) what
>> switches 'qemu-system-aarch64 -M virt' would actually take for it to work.
> 
> That's exactly why this check is wrong in libvirt IMHO. Because it is not
> based on any detected feature from QEMU it amounts to an attempt to predict
> the future.

How is dropping the check completely *not* predicting the future? If you
remove the check, then libvirt will compose command lines (for some
arches) that will *maybe* work in the future. It'll take shots in the dark.

> If the invocation syntax is supported by QEMU

That's a big "if", yes. The invocation syntax was supported for x86_64
for sure, definitely not supported for a bunch of other targets, and was
*maybe* going to be supported (at that time) in aarch64. (But I had seen
contradicting patches too on qemu-devel; for example '-bios' had been
proposed to diverge on arm from how it used to work with x86_64, ie. for
UEFI usage; ie. it looked possible that aarch64 would take one -bios and
one -pflash rather than two -pflash options.)

> then libvirt
> should not be trying to block it. libvirt should focus should be on the
> mechanism, not the usage policy

I agree.

> & this check really amounts to a usage
> policy check.

The check was intended as "we really don't know how the mechanism will
look like (apart from x86_64), so let's keep you safe".

There was absolutely no promise from qemu that aarch64 would take the
same options as x86_64, and now that it does (which is pure luck),
there's still no promise that further targets would take the same (once
they become interested in UEFI).

Thanks
Laszlo