From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVG6D-0004qI-Oa for qemu-devel@nongnu.org; Mon, 15 Feb 2016 05:09:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVG6A-00087S-CR for qemu-devel@nongnu.org; Mon, 15 Feb 2016 05:09:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVG6A-00087N-5w for qemu-devel@nongnu.org; Mon, 15 Feb 2016 05:09: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 E5E70341AF3 for ; Mon, 15 Feb 2016 10:09:41 +0000 (UTC) Date: Mon, 15 Feb 2016 18:09:29 +0800 From: Peter Xu Message-ID: <20160215100929.GB7978@pxdev.xzpeter.org> References: <1455428503-2113-1-git-send-email-peterx@redhat.com> <20160215093539.GD15724@wheatley> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160215093539.GD15724@wheatley> 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: Martin Kletzander Cc: libvir-list@redhat.com, wei@redhat.com, drjones@redhat.com, qemu-devel@nongnu.org, abologna@redhat.com On Mon, Feb 15, 2016 at 10:35:39AM +0100, Martin Kletzander wrote: > On Sun, Feb 14, 2016 at 01:41:41PM +0800, Peter Xu wrote: > > > >["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}] Yes, I'd say that this is more clear especially when the matrix is very big. Luckily for GIC versions, there is only 2x2 (2x3 if there is v4) and it keeps a small one. So IMHO this is a flavor issue and both work for me. :) Thanks. Peter