From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4uqu-0006pw-6A for qemu-devel@nongnu.org; Tue, 16 Jun 2015 13:40:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4uqo-0007Ts-Ps for qemu-devel@nongnu.org; Tue, 16 Jun 2015 13:40:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4uqo-0007TT-Ie for qemu-devel@nongnu.org; Tue, 16 Jun 2015 13:40:42 -0400 Date: Tue, 16 Jun 2015 14:40:39 -0300 From: Eduardo Habkost Message-ID: <20150616174038.GA22590@thinpad.lan.raisama.net> 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: qemu-devel@nongnu.org Cc: mimu@linux.vnet.ibm.com, borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , Andreas =?iso-8859-1?Q?F=E4rber?= , rth@twiddle.net Ping? Any feedback? I want to get this into 2.4. On Mon, Jun 08, 2015 at 04:07:38PM -0300, Eduardo Habkost wrote: > The problem: > > The existing libvirt APIs assume that if a given CPU model is runnable in a > host kernel+hardware combination, it will be always runnable on that host even > if the machine-type changes. > > That assumption is implied in some of libvirt interfaces, for example, at: > > 1) Host capabilities, which let callers know the set of CPU models > that can run in a host: > https://libvirt.org/formatcaps.html#elementHost > > "virsh capabilities" returns a CPU model name + CPU feature list, assuming > that a CPU model name has a meaning that's independent from the > machine-type. > > 2) The function that checks if a given CPU model definition > is compatible with a host (virConnectCompareCPU()), > which does not take the machine-type as argument: > http://libvirt.org/html/libvirt-libvirt-host.html#virConnectCompareCPU > > But that assumption is not true, as QEMU changes CPU models in new > machine-types when fixing bugs, or when new features (previously unsupported by > QEMU, TCG or KVM) get implemented. > > The solution: > > 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. > > * * * > > This is basically the same version I sent as an RFC in April. A git tree is > available at: > > git://github.com/ehabkost/qemu-hacks.git work/x86-cpu-custom-model > > Eduardo Habkost (2): > target-i386: Introduce "-cpu custom" > scripts: x86-cpu-model-dump script > > scripts/x86-cpu-model-dump | 322 +++++++++++++++++++++++++++++++++++++++++++++ > target-i386/cpu.c | 10 +- > 2 files changed, 331 insertions(+), 1 deletion(-) > create mode 100755 scripts/x86-cpu-model-dump > > -- > 2.1.0 > > -- Eduardo