Re: [libvirt] [PATCH] qemu: Support OVMF on aarch64 guests
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