qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC versi


From: Andrea Bolognani
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC version
Date: Fri, 19 Feb 2016 13:33:09 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]