[libvirt] [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC version
Daniel P. Berrange
berrange at redhat.com
Tue Feb 16 10:15:10 UTC 2016
On Tue, Feb 16, 2016 at 11:10:55AM +0100, Markus Armbruster wrote:
> Peter Maydell <peter.maydell at linaro.org> writes:
> > On 15 February 2016 at 20:18, Andrew Jones <drjones at redhat.com> 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
> 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.
|: 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 :|
More information about the libvir-list