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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]