On Fri, 2016-02-19 at 09:55 +0800, Peter Xu wrote:
> AFAIK, the current situation of libvirt passing the GIC version
to
> QEMU and simply reporting in case of failure is not unprecedented
> and there are a few cases where probing in advance would simply not
> be feasible.
>
> Any probing code added to libvirt would have to be kept around
> forever to ensure compatibility with current QEMU versions, so it
> should IMHO be seen as a last resort in case we can't live without
> GIC version probing while it's being implemented, properly, in QEMU.
If libvirt is the most possible consumer for the new command, I
think it might not be too hard to keep the compatibility of all
possible versions of QEMU. E.g., after we have got a better way to
query GIC version other than query-gic-capability, we can do
something like this in libvirt:
- try query-gic-capability
- if supported -> [got GIC version]
- if not supported -> try the new method
- if supported -> [got GIC version]
- if not supported -> [not support]
During the time when QEMU has both methods working (before
obsoleting the query-gic-capability QMP command), QEMU will make
sure querying in both way will get exactly the same results.
I didn't say it would be hard :)
I just said that such compatibility code would have to be kept
around forever. We already support lots and lots of similar cases
in libvirt, the difference being that in this case we would add
support for a new command *knowing in advance* that it will become
obsolete as soon as a proper implementation is available.
It might still be the right thing to do! I just want to make sure
everything's been properly considered and discussed beforehand.
Cheers.
--
Andrea Bolognani
Software Engineer - Virtualization Team