From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVFZL-0006Fe-GZ for qemu-devel@nongnu.org; Mon, 15 Feb 2016 04:35:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVFZG-00005J-Eg for qemu-devel@nongnu.org; Mon, 15 Feb 2016 04:35:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVFZG-00005D-4g for qemu-devel@nongnu.org; Mon, 15 Feb 2016 04:35:42 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 289D05A67 for ; Mon, 15 Feb 2016 09:35:41 +0000 (UTC) Date: Mon, 15 Feb 2016 10:35:39 +0100 From: Martin Kletzander Message-ID: <20160215093539.GD15724@wheatley> References: <1455428503-2113-1-git-send-email-peterx@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <1455428503-2113-1-git-send-email-peterx@redhat.com> Subject: Re: [Qemu-devel] [libvirt] [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: Peter Xu Cc: libvir-list@redhat.com, wei@redhat.com, drjones@redhat.com, qemu-devel@nongnu.org, abologna@redhat.com --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Sun, Feb 14, 2016 at 01:41:41PM +0800, Peter Xu wrote: >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. > This looks nice. I have some questions, but I'm not an expert in this area, so excuse me if they are stupid. So hardware itself supports some GIC version, let's say 3 for our case. Does that mean it can be triggered to do v2 as well? I mean is it possible that HW supports multiple versions? If yes, then I suspect there is (will be) HW that does *not* do it and that's where QEMU (or KVM) must emulate that version. If all I'm having in mind is true, then you are trying to reply with two orthogonal types of information. A) versions kernel/HW supports and B) qemu/kvm can emulate. That is fine if libvirt can choose all the versions specified (e.g. gicv2-kvm, gicv2), but if we can only select a version, then it might be worth just returning those two types of information separately, e.g.: ["v2": {"emulated": true, "kvm":true}, "v3": {"emulated": false, "kvm": true}] But as I said, I don't know the pre-requisites for this and mainly I'm not dealing with arm support now in libvirt, I'm just curious about it. >One question: how should I make this command "ARM only"? I see that >in qmp-commands.hx, I can use something like "#if defined >TARGET_ARM" to block out ARM specified commands, however how should >I do the similiar thing in qapi-schema.json? > As mentioned in the other thread, making it available everywhere and just returning a proper error message (so we can parse the class and not the error message itself) is the best choice, IMHO. >Thanks! >Peter > >Peter Xu (2): > arm: gic: add GICType > arm: gic: add "query-gic-capability" interface > > qapi-schema.json | 28 ++++++++++++++++++++++++++++ > qmp-commands.hx | 25 +++++++++++++++++++++++++ > qmp.c | 5 +++++ > scripts/qapi.py | 1 + > 4 files changed, 59 insertions(+) > >-- >2.4.3 > >-- >libvir-list mailing list >libvir-list@redhat.com >https://www.redhat.com/mailman/listinfo/libvir-list --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWwZvrAAoJEAgfwp8kF4bd4kMP/jS+jcCn5mcKkiEOk9kD2vfR 8d/IH3l502wCJqgNnXrF8tWNG2Tt8oXXWBINtnq2xBHkCkbGxLIvMDI1oTWeDX0Q 1aqDQ55kGNGKAg23UG4SGHemIueXE4bjc2ghUm+g4N+RGu5bFOBbnFGcPng+Nc56 troH2pTx3/ZHTJi18PAnnsbkrNnTJioZwabe8VIPCG4KsJZDPAzyMHdKk+Ku2WYq 3dmkBWEaeOWI4eqeTa8XpxqFOBEKbVbAWat+jsi+mUeMMFMhvUy/T4sJDYo0HMBR eA1e6NXuDtXVFuO2M7Ku6YQw2UQ3lOd2WLelcmpspxDVwWA3Z2pH8e0KgbaTr55Q SuqBfw7Q23pRSeO0cny+9Ziiju/rImdSJsh34kUZEf+rMVhkYjX06utCzoy7h3C+ +mUvzEpbNHb6oQEchgRegCPZ3BMACpf6AM+vs5zXk31FD8DCGb6I07QdKvKLpDnZ tCkpWiIRHo6RFsvZr5CpUE6NvTtwAbBQGVaF/4Ykj2NbM2hC8iEkNrMqMfFw18dU AHUE7A5YSimJ8zEBKz24LhxFjhBsvCvam0EfWswkX+mMH4zSNtTqnoophAbIsTHm cBIuKQWCv4jWaZxO9eVBTIQZMftqgB1aPPFcVp6l4F7XY7VOpfg0Q4R54ezrNCnP V8tkZQzzAebLZuNitQWK =1gD+ -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt--