All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Denemark <jdenemar@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org,
	borntraeger@de.ibm.com, "Igor Mammedov" <imammedo@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>,
	rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models
Date: Mon, 8 Jun 2015 22:18:35 +0200	[thread overview]
Message-ID: <20150608201835.GM3525@orkuz.home> (raw)
In-Reply-To: <1433790460-30679-1-git-send-email-ehabkost@redhat.com>

On Mon, Jun 08, 2015 at 16:07:38 -0300, Eduardo Habkost wrote:
...
> libvirt can solve this problem partially by making sure every feature in a CPU
> model is explicitly configured, instead of (incorrectly) expecting that a named
> CPU model will never change in QEMU. But this doesn't solve the problem
> completely, because it is still possible that new features unknown to libvirt
> get enabled in the default CPU model in future machine-types (that's very
> likely to happen when we introduce new KVM features, for example).
> 
> So, to make sure no new feature will be ever enabled without the knowledge of
> libvirt, add a "-cpu custom" mode, where no CPU model data is loaded at all,
> and everything needs to be configured explicitly using CPU properties. That
> means no CPU features will ever change depending on machine-type or accelerator
> capabilities when using "-cpu custom".
> 
>                               * * *
> 
> I know that this is basically the opposite of what we were aiming at in the
> last few month^Wyears, where we were struggling to implement probing interfaces
> to expose machine-type-dependent data for libvirt. But, at least the fact that
> we could implement the new approach using a 9-line patch means we were still
> going in the right direction. :)
> 
> To help libvirt in the transition, a x86-cpu-model-dump script is provided,
> that will generate a config file that can be loaded using -readconfig, based on
> the -cpu and -machine options provided in the command-line.

Thanks Eduardo, I never was a big fan of moving (or copying) all the CPU
configuration data to libvirt, but now I think it actually makes sense.
We already have a partial copy of CPU model definitions in libvirt
anyway, but as QEMU changes some CPU models in some machine types (and
libvirt does not do that) we have no real control over the guest CPU
configuration. While what we really want is full control to enforce
stable guest ABI.

I will summarize my ideas on how libvirt should be using -cpu custom and
send them to libvirt-list soon.

Jirka

  parent reply	other threads:[~2015-06-08 20:18 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08 19:07 [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models Eduardo Habkost
2015-06-08 19:07 ` [Qemu-devel] [PATCH 1/2] target-i386: Introduce "-cpu custom" Eduardo Habkost
2015-06-08 19:07 ` [Qemu-devel] [PATCH 2/2] scripts: x86-cpu-model-dump script Eduardo Habkost
2015-06-08 20:18 ` Jiri Denemark [this message]
2015-06-09  8:56   ` [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models Daniel P. Berrange
2015-06-09 13:16     ` Eduardo Habkost
2015-06-23 12:32   ` Andreas Färber
2015-06-23 15:08     ` Eduardo Habkost
2015-06-23 15:32       ` Michael S. Tsirkin
2015-06-23 15:58         ` Eduardo Habkost
2015-06-23 16:15           ` Andreas Färber
2015-06-23 16:25             ` Daniel P. Berrange
2015-06-23 16:33               ` Michael S. Tsirkin
2015-06-23 16:38                 ` Eduardo Habkost
2015-06-23 16:44                   ` Andreas Färber
2015-06-23 17:08                     ` Eduardo Habkost
2015-06-23 17:18                       ` Andreas Färber
2015-06-23 17:27                         ` Daniel P. Berrange
2015-06-23 17:41                           ` Andreas Färber
2015-06-23 17:45                             ` Eduardo Habkost
2015-06-23 17:58                               ` Andreas Färber
2015-06-23 18:05                                 ` Daniel P. Berrange
2015-06-23 18:11                                 ` Eduardo Habkost
2015-06-23 17:55                             ` Daniel P. Berrange
2015-06-23 17:39                         ` Eduardo Habkost
2015-06-23 18:35                           ` Andreas Färber
2015-06-23 19:25                             ` Eduardo Habkost
2015-06-23 19:41                               ` Andreas Färber
2015-06-23 19:53                                 ` Eduardo Habkost
2015-06-23 20:26                                 ` Eduardo Habkost
2015-06-23 21:38                                   ` Michael S. Tsirkin
2015-06-23 16:42                 ` Daniel P. Berrange
2015-06-23 16:47                   ` Andreas Färber
2015-06-23 17:11                     ` Eduardo Habkost
2015-06-23 21:34                       ` Michael S. Tsirkin
2015-06-24 14:24                         ` Eduardo Habkost
2015-06-24 14:37                           ` Michael S. Tsirkin
2015-06-24 15:44                             ` [Qemu-devel] Not introducing new host-side requirements on new machine-type versions (was Re: [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models) Eduardo Habkost
2015-06-24 15:58                               ` Andreas Färber
2015-06-24 16:08                                 ` Eduardo Habkost
2015-06-24 16:15                                   ` Andreas Färber
2015-06-24 15:59                               ` Paolo Bonzini
2015-06-23 17:13                     ` [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models Daniel P. Berrange
2015-06-23 17:29                       ` Andreas Färber
2015-06-23 17:42                         ` Eduardo Habkost
2015-06-23 17:55                           ` Andreas Färber
2015-06-23 17:58                             ` Daniel P. Berrange
2015-06-23 21:28                           ` Michael S. Tsirkin
2015-06-24 14:18                             ` Eduardo Habkost
2015-06-24 14:24                               ` Michael S. Tsirkin
2015-06-23 21:26                       ` Michael S. Tsirkin
2015-06-23 21:23                   ` Michael S. Tsirkin
2015-06-24  8:52                     ` Daniel P. Berrange
2015-06-24 10:31                       ` Michael S. Tsirkin
2015-06-24 14:16                     ` Eduardo Habkost
2015-06-24 14:19                       ` Michael S. Tsirkin
2015-06-24 14:35                         ` Andreas Färber
2015-06-24 14:57                           ` Michael S. Tsirkin
2015-06-24 15:43                             ` Andreas Färber
2015-06-24 14:38                       ` Paolo Bonzini
2015-06-24 14:54                         ` Peter Maydell
2015-06-24 14:56                           ` Paolo Bonzini
2015-06-24 15:58                         ` Eduardo Habkost
2015-06-24 16:00                           ` Paolo Bonzini
2015-06-23 16:40               ` Andreas Färber
2015-06-23 16:53                 ` Daniel P. Berrange
2015-06-23 17:10                   ` Andreas Färber
2015-06-23 17:24                     ` Eduardo Habkost
2015-06-23 17:31                       ` Daniel P. Berrange
2015-06-23 16:32             ` Eduardo Habkost
2015-06-23 17:01               ` Andreas Färber
2015-06-23 15:51       ` Daniel P. Berrange
2015-06-23 15:56         ` Michael S. Tsirkin
2015-06-23 16:00           ` Daniel P. Berrange
2015-06-23 16:30             ` Michael S. Tsirkin
2015-06-24  9:20     ` Jiri Denemark
2015-06-24 10:21       ` Michael S. Tsirkin
2015-06-24 10:31         ` Daniel P. Berrange
2015-06-24 10:40           ` Michael S. Tsirkin
2015-06-24 10:32         ` Paolo Bonzini
2015-06-16 17:40 ` 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=20150608201835.GM3525@orkuz.home \
    --to=jdenemar@redhat.com \
    --cc=afaerber@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mimu@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.