qemu-devel
[Top][All Lists]
Advanced

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

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


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [libvirt] [RFC PATCH 0/2] ARM: add QMP command to query GIC version
Date: Tue, 16 Feb 2016 12:38:22 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

On Tue, Feb 16, 2016 at 01:27:55PM +0100, Andrea Bolognani wrote:
> 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?

The cost of invoking QEMU for each architecture and probing capabilities
is already higher than we would like. If we multiply that cost by the
number of machine types, it makes the problem orders of magnitude worse,
so we cannot go that route.

This is a key reason why we would like to be able to probe properties
against QEMU classses without instantiating them. ie so we can launch
QEMU once with "-m none" and still be able to query specific properties
we want from the 'virt' machine type. A small step towards this was
made with a patch we landed to let us register properties against
classes in QOM, instead of against objects. We've not done work to
convert code internally to use this facility yet though.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]