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