From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45308) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWS64-0002a0-Lo for qemu-devel@nongnu.org; Thu, 18 Feb 2016 12:10:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWS61-00011N-E5 for qemu-devel@nongnu.org; Thu, 18 Feb 2016 12:10:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWS61-00011I-7n for qemu-devel@nongnu.org; Thu, 18 Feb 2016 12:10:29 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 641B47EBA0 for ; Thu, 18 Feb 2016 17:10:28 +0000 (UTC) Message-ID: <1455815421.3968.12.camel@redhat.com> From: Andrea Bolognani Date: Thu, 18 Feb 2016 18:10:21 +0100 In-Reply-To: <20160218165208.vdf4ycsrn3qwxd2x@hawk.localdomain> References: <1455428503-2113-1-git-send-email-peterx@redhat.com> <87povy5mim.fsf@blackfin.pond.sub.org> <20160215103440.GC7978@pxdev.xzpeter.org> <87y4amhuz2.fsf@blackfin.pond.sub.org> <20160215152205.GC898@redhat.com> <20160218044056.GL7978@pxdev.xzpeter.org> <20160218165208.vdf4ycsrn3qwxd2x@hawk.localdomain> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC version List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones , Peter Xu Cc: wei@redhat.com, libvir-list@redhat.com, qemu-devel@nongnu.org, Markus Armbruster On Thu, 2016-02-18 at 17:52 +0100, Andrew Jones wrote: > > Is this work on any of our todo list (or anyone has started the > > prototyping)? > >=C2=A0 > > It seems reasonable to provide such a generic interface, rather than > > adding a "query-gic-capability" for GIC versions only. The problem > > is that, I am not sure how eagerly we are wanting this GIC > > interface, and when will this framework be there in QOM. >=C2=A0 > We want it eagerly :-) This type of a rabbit hole is likely why Daniel > was suggesting we do more in libvirt. I'm still not sure we want to > probe both kvm and qemu from libvirt though, so I'm still in favor of > an improved qemu probing method being worked out. >=C2=A0 > I don't know what the policy is for deprecating QMP commands, but I > wonder if we can't introduce a QMP command now, and then, after working > out the QOM extensions, we could shift to it, deprecating this QMP > command and any others that would no longer be needed. 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. Cheers. --=C2=A0 Andrea Bolognani Software Engineer - Virtualization Team