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

[Daniel P. Berrange]

On Tue, Feb 16, 2016 at 11:10:55AM +0100, Markus Armbruster wrote:
> Peter Maydell <address@hidden> writes:
> 
> > On 15 February 2016 at 20:18, Andrew Jones <address@hidden> 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?

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.

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