From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWGP4-0003h6-Fa for qemu-devel@nongnu.org; Wed, 17 Feb 2016 23:41:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWGOy-0004II-DQ for qemu-devel@nongnu.org; Wed, 17 Feb 2016 23:41:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWGOy-0004IC-6M for qemu-devel@nongnu.org; Wed, 17 Feb 2016 23:41:16 -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 38517C057EC2 for ; Thu, 18 Feb 2016 04:41:15 +0000 (UTC) Date: Thu, 18 Feb 2016 12:40:56 +0800 From: Peter Xu Message-ID: <20160218044056.GL7978@pxdev.xzpeter.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160215152205.GC898@redhat.com> 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: "Daniel P. Berrange" Cc: wei@redhat.com, drjones@redhat.com, qemu-devel@nongnu.org, libvir-list@redhat.com, Markus Armbruster , abologna@redhat.com On Mon, Feb 15, 2016 at 03:22:05PM +0000, Daniel P. Berrange wrote: > On Mon, Feb 15, 2016 at 04:08:33PM +0100, Markus Armbruster wrote: > > Peter Xu writes: > > > > > On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote: > > >> Peter Xu writes: > > >> > > >> > For ARM platform, we still do not have any interface to query > > >> > whether current QEMU/host support specific GIC version. This > > >> > patchset is trying to add one QMP interface for that. By querying > > >> > the GIC capability using the new interface, one should know exactly > > >> > what GIC version(s) the platform will support. The capability bits > > >> > will be decided by both QEMU and host kernel. > > >> > > > >> > The current patchset only provides interface for review. Its handler > > >> > is a fake one which returns empty always. > > >> > > > >> > The command interface I am planning to add is something like this: > > >> > > > >> > -> { "execute": "query-gic-capability" } > > >> > <- { "return": [ "gicv2", "gicv2-kvm", "gicv3-kvm" ] } > > >> > > > >> > Currently, all the possible supported GIC versions are: > > >> > > > >> > - gicv2: GIC version 2 without kernel IRQ chip > > >> > - gicv2-kvm: GIC version 2 with kernel IRQ chip > > >> > - gicv3: GIC version 3 without kernel IRQ chip (not supported) > > >> > - gicv3-kvm: GIC version 3 with kernel IRQ chip > > >> > > > >> > Since "gicv3" is still not supported (to use GICv3, kernel irqchip > > >> > support is required for now, which corresponds to "gicv3-kvm"), > > >> > currently the maximum superset of the result should be: > > >> > > > >> > ["gicv2", "gicv2-kvm", "gicv3-kvm"] > > >> > > > >> > Please help review whether the interface suits our need, also please > > >> > point out any error I have made. > > >> > > >> Adding ad hoc queries as we go won't scale. Is there really no generic > > >> way to get this information, e.g. with qom-get? > > > > > > Haven't used "qom-get" before, but it seems to fetch one property > > > for a specific object. If so, will it be strange to hide some > > > capability bits into every GIC objects (though there is possibly > > > one object)? > > > > Pardon my ignorance... what are these "GIC objects"? > > > > What exactly is the "GIC type", and how would the result of > > query-gic-capability be used? > > > > > I agree that we should keep the interface as simple as > > > possible. I see that there are already commands that works just like > > > this one, which is to query some capabilities from QEMU, like: > > > > > > - query-dump-guest-memory-capability > > > - query-migrate-capabilities > > > > I'm not saying we must not add another ad hoc query. I'm trying to > > figure out whether existing generic infrastructure can serve, or be > > adapted to serve. Once we establish the answer is "no" or "badly", I'm > > willing to consider the ad hoc query. > > Looking at this from the POV of solving the generic problem, what we > have here is an object with an integer property, for which only certain > values are permitted based on what host kernel/hardware we're runing > on. > > So to solve this generically, we would need a way to provide information > in QOM as to what permitted values are for any given property. This would > make sense for at least bool, int and enum properties, since they can all > potentially have scenarios where the possible range of values is greater > than the currently permissible range of values. Is this work on any of our todo list (or anyone has started the prototyping)? 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. Thanks. Peter > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|