From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaxZ1-0008Q3-N8 for qemu-devel@nongnu.org; Tue, 01 Mar 2016 22:35:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaxYy-0007HZ-EC for qemu-devel@nongnu.org; Tue, 01 Mar 2016 22:35:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59317) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaxYy-0007GJ-6H for qemu-devel@nongnu.org; Tue, 01 Mar 2016 22:35:00 -0500 Date: Wed, 2 Mar 2016 11:34:44 +0800 From: Peter Xu Message-ID: <20160302033444.GA5730@pxdev.xzpeter.org> References: <1456224728-28163-1-git-send-email-peterx@redhat.com> <1456224728-28163-2-git-send-email-peterx@redhat.com> <1456842059.3566.11.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1456842059.3566.11.camel@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/3] arm: gic: add GICType List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Bolognani Cc: wei@redhat.com, peter.maydell@linaro.org, drjones@redhat.com, armbru@redhat.com, mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org On Tue, Mar 01, 2016 at 03:20:59PM +0100, Andrea Bolognani wrote: > On Tue, 2016-02-23 at 18:52 +0800, Peter Xu wrote: > > +{ 'enum': 'GICType', 'data': [ 'gicv2', 'gicv3', 'gicv2-kvm', 'gicv3= -kvm' ] } >=20 > Wouldn't this conflate the use of accel=3D and kernel_irqchip=3D option= s? AFAIU, it's not a problem. Let me paste some lines from the original RFC thread which explains the definition of the entries: - 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 (from https://lists.gnu.org/archive/html/qemu-devel/2016-02/msg02882.html= ) So... what I understand is that, we are not talking about "accel=3D" at all. Instead, we are talking about "kernel_irqchip=3D" only. Or say, all these GIC version information we provide from QEMU does not tell whether KVM is supported or not (for "accel=3D", it is provided by another QMP message named "query-kvm"). We are only talking about which kind of GIC we support. In our case, for each version, it could be supported either in userspace, or in kernel. >=20 > IIUC, depending on the hardware, you might find yourself in the > following situation: >=20 > =C2=A0 accel=3Dtcg,gic-version=3D3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unavailable > =C2=A0 accel=3Dkvm,kernel_irqchip=3Doff,gic-version=3D3=C2=A0=C2=A0unav= ailable As explained above, IIUC, both of these two "unavailable" ones correspond to "gicv3" entry of the results. > =C2=A0 accel=3Dkvm,gic-version=3D3=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0available And this one corresponds to "gicv3-kvm" entry. >=20 > so I'd expect the output to be something like >=20 > =C2=A0 [ "v2": { "tcg": true, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= "kvm-without-kernel-irqchip": true, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= "kvm": true }, > =C2=A0=C2=A0=C2=A0=C2=A0"v3": { "tcg": false, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= "kvm-without-kernel-irqchip": false, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= "kvm": true } ] Actually, this reminded me about the "kernel_irqchip=3Dsplit" case. Do we need to consider that one? AFAIK, splitted irqchip is only used for x86 currently. Whether ARM will possibly support splitted kernel irqchip one day just like x86? If so, I would prefer to change the query result layout from array to dict, like: [ "v2": { "emulated": true, "split": false, "kernel": true }, "v3": { "emulated": false, "split": false, "kernel": true } ] Since the matrix is big enough (2x3) to consider drop the array format (I'd admit maybe dict is always the best one...). Peter >=20 > Since libvirt currently doesn't have support for the > kernel_irqchip=3D option, it would only take the "tcg" and "kvm" > values into account; on the other hand, if at some point > libvirt will grow support for that option it would be able to > retrieve all the required information. >=20 > Cheers. >=20 > --=C2=A0 > Andrea Bolognani > Software Engineer - Virtualization Team