qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Bolognani <abologna@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Wei Huang <wei@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Andrew Jones <drjones@redhat.com>,
	Libvirt <libvir-list@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Peter Xu <peterx@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [libvirt] [RFC PATCH 0/2] ARM: add QMP command to query GIC version
Date: Tue, 16 Feb 2016 14:14:57 +0100	[thread overview]
Message-ID: <1455628497.4617.92.camel@redhat.com> (raw)
In-Reply-To: <20160216123822.GD11370@redhat.com>

On Tue, 2016-02-16 at 12:38 +0000, Daniel P. Berrange wrote:
> > > 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.

So, until such support lands in QEMU, is there really anything we
can do in libvirt beside passing through whatever value the user
has specified in the domain XML and report QEMU's error on failure?

I had underestimated the performance implications of spawning more
QEMU processes, thanks for highlighting them.

Cheers.

-- 
Andrea Bolognani
Software Engineer - Virtualization Team

  reply	other threads:[~2016-02-16 13:15 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-14  5:41 [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC version Peter Xu
2016-02-14  5:41 ` [Qemu-devel] [RFC PATCH 1/2] arm: gic: add GICType Peter Xu
2016-02-14  5:41 ` [Qemu-devel] [RFC PATCH 2/2] arm: gic: add "query-gic-capability" interface Peter Xu
2016-02-15  6:54 ` [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC version Wei Huang
2016-02-15  7:34   ` Peter Xu
2016-02-15  7:49     ` Fam Zheng
2016-02-15  9:35 ` [Qemu-devel] [libvirt] " Martin Kletzander
2016-02-15  9:41   ` Peter Maydell
2016-02-15 12:16     ` Andrew Jones
2016-02-15 12:27       ` Pavel Fedin
2016-02-15 10:09   ` Peter Xu
2016-02-15  9:52 ` [Qemu-devel] " Markus Armbruster
2016-02-15 10:34   ` Peter Xu
2016-02-15 15:08     ` Markus Armbruster
2016-02-15 15:21       ` Peter Maydell
2016-02-15 19:40         ` Markus Armbruster
2016-02-15 20:18           ` Andrew Jones
2016-02-15 20:32             ` Peter Maydell
2016-02-16 10:10               ` Markus Armbruster
2016-02-16 10:15                 ` Daniel P. Berrange
2016-02-16 12:05                   ` [Qemu-devel] [libvirt] " Andrea Bolognani
2016-02-16 12:09                     ` Peter Maydell
2016-02-16 12:20                       ` Andrea Bolognani
2016-02-16 12:15                     ` Daniel P. Berrange
2016-02-16 12:27                       ` Andrea Bolognani
2016-02-16 12:38                         ` Daniel P. Berrange
2016-02-16 13:14                           ` Andrea Bolognani [this message]
2016-02-15 15:22       ` [Qemu-devel] " Daniel P. Berrange
2016-02-18  4:40         ` Peter Xu
2016-02-18 16:52           ` Andrew Jones
2016-02-18 17:10             ` Andrea Bolognani
2016-02-19  1:55               ` Peter Xu
2016-02-19 12:33                 ` Andrea Bolognani
2016-02-22  1:35                   ` Peter Xu
2016-02-29 16:30                     ` Andrea Bolognani
2016-03-01  2:19                       ` Peter Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1455628497.4617.92.camel@redhat.com \
    --to=abologna@redhat.com \
    --cc=berrange@redhat.com \
    --cc=drjones@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wei@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).