[libvirt] [RFC PATCH 0/2] ARM: add QMP command to query GIC version

Peter Xu peterx at redhat.com
Mon Feb 15 10:09:29 UTC 2016

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. :)


More information about the libvir-list mailing list