qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Denemark <jdenemar@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: libvir-list@redhat.com, "Igor Mammedov" <imammedo@redhat.com>,
	qemu-devel@nongnu.org, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] libvirt<->QEMU interfaces for CPU models
Date: Fri, 1 Mar 2013 14:28:37 +0100	[thread overview]
Message-ID: <20130301132837.GF3375700@orkuz.home> (raw)
In-Reply-To: <20130221145818.GK16618@otherpad.lan.raisama.net>

On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote:
> = Querying host capabilities =
> 
> Requirement: libvirt needs to know which feature can really be enabled, before
> it tries to start a VM, and before it tries to start a live-migration process.
> 
> The set of available capabilities depend on:
> 
>   • Host CPU (hardware) capabilities;
>   • Kernel capabilities (reported by GET_SUPPORTED_CPUID);
>   • QEMU capabilities;
>   • Specific configuration options (e.g. in-kernel IRQ chip is required for
>     some features).

Actually, one more thing. Can any of these requirements change while a
host is up and QEMU is not upgraded? I believe, host CPU capabilities
can only change when the host starts. Kernel capabilities are a bit less
clear since I guess they could possibly change when kvm module is
unloaded and loaded back with a different options. QEMU capabilities
should only change when different version is installed. And the specific
configuration options are the most unclear to me. The reason I'm asking
is whether libvirt could run-time cache CPU definitions (including all
model details) in the same way we currently cache QEMU capabilities,
such as availability of specific QMP commands.

Jirka

  parent reply	other threads:[~2013-03-01 13:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20130221145818.GK16618@otherpad.lan.raisama.net>
2013-03-01 13:12 ` [Qemu-devel] libvirt<->QEMU interfaces for CPU models Jiri Denemark
2013-03-01 15:02   ` Eduardo Habkost
2013-03-01 22:56     ` Jiri Denemark
2013-03-25 20:37       ` Eduardo Habkost
2013-03-01 18:31   ` Andreas Färber
2013-03-01 18:34     ` Daniel P. Berrange
2013-03-01 19:01       ` Eduardo Habkost
2013-03-01 18:58     ` Eduardo Habkost
2013-03-04 10:33       ` Daniel P. Berrange
2013-03-01 13:28 ` Jiri Denemark [this message]
2013-03-01 15:31   ` Eduardo Habkost

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=20130301132837.GF3375700@orkuz.home \
    --to=jdenemar@redhat.com \
    --cc=afaerber@suse.de \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).