From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z23VM-0005F3-9Z for qemu-devel@nongnu.org; Mon, 08 Jun 2015 16:18:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z23VH-0007Z7-7O for qemu-devel@nongnu.org; Mon, 08 Jun 2015 16:18:44 -0400 Received: from smtp.vivo.cz ([85.132.139.19]:43983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z23VH-0007YF-0L for qemu-devel@nongnu.org; Mon, 08 Jun 2015 16:18:39 -0400 Date: Mon, 8 Jun 2015 22:18:35 +0200 From: Jiri Denemark Message-ID: <20150608201835.GM3525@orkuz.home> References: <1433790460-30679-1-git-send-email-ehabkost@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1433790460-30679-1-git-send-email-ehabkost@redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org, borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= , rth@twiddle.net 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