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.

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?

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(+)

On Mon, Feb 15, 2016 at 12:54:57AM -0600, Wei Huang wrote: > On 2/13/16 23:41, Peter Xu wrote: > > 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? > > This situation is similar to "rtc-reset-reinjection", right? I think You > can disable this feature on other arch's by setting > QERR_FEATURE_DISABLED in file like monitor.c. Yes. Will include this when post the real patches.

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.

I know Pavel Fedin was trying to revive kernel_irqchip=off once, but I don't know if that effort was abandoned or not.

I think it could be a nice-to-have, in order to help isolate bugs with KVM, but I agree running that way wouldn't be the norm.

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.

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?

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)?

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

So... besides the original proposal, what about adding a generic QMP command to query all kinds of capabilities (and let GIC be the first item)? Or any other way to avoid adding a new command?

On 15 February 2016 at 15:08, Markus Armbruster <armbru(a)redhat.com&gt; 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: >>> 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? The GIC type (for our purposes) is the revision of the interrupt controller supported by the host, which comes in two versions (v2 and v3). These are not compatible, unless your host has the v3-with-v2-compat flavour. If a host is v3-only, it is not possible for it to give the guest a v2 virtual interrupt controller; if v2, it can't give the guest a v3 virtual interrupt controller. (If you ask QEMU to do this via command line options we will report an error at startup.)

The underlying aim is to allow libvirt to say "this VM config won't work on this host", rather than ploughing blindly on and creating a VM config that always errors on startup.

The "GIC object" presumably is the GIC QOM device object. However we do the "does this host support this GIC version?" check in QEMU before we ever create the GIC device object, so trying to probe it for properties isn't going to work.

The only other QOM object potentially available to probe would be the machine (board) object. However as I understand it libvirt does all its probing with the "none" machine type, and it seems a bit odd to put a bunch of properties on the "none" machine type. It would be possible though I guess.

On Mon, Feb 15, 2016 at 08:40:54PM +0100, Markus Armbruster wrote: > How would the command line look like? > Here is what is available today # select gicv2 (this work with and without KVM) qemu-system-aarch64 -M virt # v2 is the default qemu-system-aarch64 -M virt,gic-version=2 ... # select gicv3 (only works with KVM) qemu-system-aarch64 -M virt,gic-version=3 ...

# select whatever the host has qemu-system-aarch64 -M virt,gic-version=host ...

Peter Maydell <peter.maydell(a)linaro.org&gt; writes: > On 15 February 2016 at 20:18, Andrew Jones <drjones(a)redhat.com&gt; wrote: >> On Mon, Feb 15, 2016 at 08:40:54PM +0100, Markus Armbruster wrote: >>> How would the command line look like? >>> >> >> Here is what is available today >> >> # select gicv2 (this work with and without KVM) >> qemu-system-aarch64 -M virt # v2 is the default >> qemu-system-aarch64 -M virt,gic-version=2 ... >> >> # select gicv3 (only works with KVM) >> qemu-system-aarch64 -M virt,gic-version=3 ... > > This will work with TCG once we get the GICv3 emulation upstream. > >> # select whatever the host has >> qemu-system-aarch64 -M virt,gic-version=host ... > > This only works with KVM (like -cpu host). Aha, it's a machine option. Therefore, the generic direct solution would be command line introspection. A couple of remarks. We don't have comprehensive command line introspection. There's only query-command-line-options, but it's incomplete and insufficiently expressive. We usually sidestep command line introspection and introspect the corresponding QMP command, or we "look for a witness" in QMP, i.e. some introspectible indicator for the non-introspectible feature we need to know. The is no QMP command corresponding to --machine. There's a long term vision to start QEMU with a blank slate, then configure everything via QMP. With that, QMP introspection would cover machine options. Of course, visions aren't going to help you now. Even if there was a QMP command, the way we do --machine options would defeat QMP introspection: they're QOM properties, defined in code. Defining things in code is the most flexible solution, but it makes reasoning about them *much* harder: the only general way to learn what code does is run it. This is fundamentally incompatible with introspection. In other words, QOM's design sacrifices introspectability for flexibility. The flexibility isn't actually needed most of the time, but it defeats introspection all of the time. For me, this was an design mistake. We made the same mistake before, with migration. I figure we'll need to crack the QOM introspection problem to at least some useful degree. But it's going to be a lot of work. A less flexible, introspectible, data-driven interface could be layered on top of the code-driven one. With as many users as possible converted to the data-driven interface, the flexibility then defeats introspection only where we actually use the flexibility. Back to GIV. Recognized values of gic-version are fixed at compile time: 2, 3, host. Once again, QOM does things in code rather than data: the set of values is defined in the setter function virt_set_gic_version(). Some values are accepted only together with other configuration: 3 requires accel=kvm (for now), host requires -cpu host. Static introspection can't show such constraints. Would the proposed query-gic-capability show them? How?

The idea is to add this information to domain capabilities, which already have virtualization type, architecture and machine type as inputs. Since GIC is only available for the virt machine type on ARM hosts, and the GIC versions might be limited by using TCG instead of KVM, it seems like it would fit nicely...

On Tue, 2016-02-16 at 10:15 +0000, Daniel P. Berrange wrote: > > Back to GIV.  Recognized values of gic-version are fixed at compile > > time: 2, 3, host.  Once again, QOM does things in code rather than data: > > the set of values is defined in the setter function > > virt_set_gic_version(). > >  > > Some values are accepted only together with other configuration: 3 > > requires accel=kvm (for now), host requires -cpu host.  Static > > introspection can't show such constraints. > >  > > Would the proposed query-gic-capability show them?  How? >  > Also bear in mind that libvirt probes capabilities using '-m none' so > you're not going to have any 'virt' machine type instantiated when > probing is done. The idea is to add this information to domain capabilities, which already have virtualization type, architecture and machine type as inputs.

On Tue, 2016-02-16 at 12:15 +0000, Daniel P. Berrange wrote: > On Tue, Feb 16, 2016 at 01:05:45PM +0100, Andrea Bolognani wrote: > > On Tue, 2016-02-16 at 10:15 +0000, Daniel P. Berrange wrote: > > > > Back to GIV.  Recognized values of gic-version are fixed at compile > > > > time: 2, 3, host.  Once again, QOM does things in code rather than data: > > > > the set of values is defined in the setter function > > > > virt_set_gic_version(). > > > >   > > > > Some values are accepted only together with other configuration: 3 > > > > requires accel=kvm (for now), host requires -cpu host.  Static > > > > introspection can't show such constraints. > > > >   > > > > Would the proposed query-gic-capability show them?  How? > > >   > > > Also bear in mind that libvirt probes capabilities using '-m none' so > > > you're not going to have any 'virt' machine type instantiated when > > > probing is done. > >  > > The idea is to add this information to domain capabilities, which > > already have virtualization type, architecture and machine type as > > inputs. >  > Regardless of the way it is exposed in libvirt API, when libvirt probes > for capabilities it will *always* use '-m none'. Domain capabilities are currently derived almost entirely from data taken from virQEMUCaps, but is there anything stopping us from calling QEMU with the appropriate machine type from qemuConnectGetDomainCapabilities() to query for machine type dependent domain capabilities such as supported values for the gic-version property?

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.

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

On Thu, 2016-02-18 at 17:52 +0100, Andrew Jones wrote: > > 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. >  > We want it eagerly :-) This type of a rabbit hole is likely why Daniel > was suggesting we do more in libvirt. I'm still not sure we want to > probe both kvm and qemu from libvirt though, so I'm still in favor of > an improved qemu probing method being worked out. >  > I don't know what the policy is for deprecating QMP commands, but I > wonder if we can't introduce a QMP command now, and then, after working > out the QOM extensions, we could shift to it, deprecating this QMP > command and any others that would no longer be needed. AFAIK, the current situation of libvirt passing the GIC version to QEMU and simply reporting in case of failure is not unprecedented and there are a few cases where probing in advance would simply not be feasible. Any probing code added to libvirt would have to be kept around forever to ensure compatibility with current QEMU versions, so it should IMHO be seen as a last resort in case we can't live without GIC version probing while it's being implemented, properly, in QEMU.

I didn't say it would be hard :) I just said that such compatibility code would have to be kept around forever. We already support lots and lots of similar cases in libvirt, the difference being that in this case we would add support for a new command *knowing in advance* that it will become obsolete as soon as a proper implementation is available. It might still be the right thing to do! I just want to make sure everything's been properly considered and discussed beforehand.

On Mon, 2016-02-22 at 09:35 +0800, Peter Xu wrote: > On Fri, Feb 19, 2016 at 01:33:09PM +0100, Andrea Bolognani wrote: > >  > > I didn't say it would be hard :) > >  > > I just said that such compatibility code would have to be kept > > around forever. We already support lots and lots of similar cases > > in libvirt, the difference being that in this case we would add > > support for a new command *knowing in advance* that it will become > > obsolete as soon as a proper implementation is available. > >  > > It might still be the right thing to do! I just want to make sure > > everything's been properly considered and discussed beforehand. >  > I totally agree with you to think more before doing. :) So, anyone else willing to give their $0.2 on how to implement this The Right Way™? I just skimmed the whole thread again and it doesn't look to me like any consensus has been reached.

Cheers. --  Andrea Bolognani Software Engineer - Virtualization Team