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

On Mon, Feb 15, 2016 at 03:22:05PM +0000, Daniel P. Berrange wrote: > On Mon, Feb 15, 2016 at 04:08:33PM +0100, Markus Armbruster wrote: > > Peter Xu <peterx(a)redhat.com&gt; writes: > > > > > On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote: > > >> Peter Xu <peterx(a)redhat.com&gt; writes: > > >> > > >> > 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. > > >> > > >> Adding ad hoc queries as we go won't scale. Is there really no generic > > >> way to get this information, e.g. with qom-get? > > > > > > Haven't used "qom-get" before, but it seems to fetch one property > > > for a specific object. If so, will it be strange to hide some > > > capability bits into every GIC objects (though there is possibly > > > one object)? > > > > Pardon my ignorance... what are these "GIC objects"? > > > > What exactly is the "GIC type", and how would the result of > > query-gic-capability be used? > > > > > I agree that we should keep the interface as simple as > > > possible. I see that there are already commands that works just like > > > this one, which is to query some capabilities from QEMU, like: > > > > > > - query-dump-guest-memory-capability > > > - query-migrate-capabilities > > > > I'm not saying we must not add another ad hoc query. I'm trying to > > figure out whether existing generic infrastructure can serve, or be > > adapted to serve. Once we establish the answer is "no" or "badly", I'm > > willing to consider the ad hoc query. > > Looking at this from the POV of solving the generic problem, what we > have here is an object with an integer property, for which only certain > values are permitted based on what host kernel/hardware we're runing > on. > > So to solve this generically, we would need a way to provide information > in QOM as to what permitted values are for any given property. This would > make sense for at least bool, int and enum properties, since they can all > potentially have scenarios where the possible range of values is greater > than the currently permissible range of values. Is this work on any of our todo list (or anyone has started the prototyping)? It seems reasonable to provide such a generic interface, rather than adding a "query-gic-capability" for GIC versions only. The problem is that, I am not sure how eagerly we are wanting this GIC interface, and when will this framework be there in QOM.

Thanks. Peter > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|