From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2FKm-0000fM-RJ for qemu-devel@nongnu.org; Tue, 09 Jun 2015 04:56:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2FKi-00051r-TD for qemu-devel@nongnu.org; Tue, 09 Jun 2015 04:56:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2FKi-00051A-J8 for qemu-devel@nongnu.org; Tue, 09 Jun 2015 04:56:32 -0400 Date: Tue, 9 Jun 2015 09:56:25 +0100 From: "Daniel P. Berrange" Message-ID: <20150609085625.GC2089@redhat.com> References: <1433790460-30679-1-git-send-email-ehabkost@redhat.com> <20150608201835.GM3525@orkuz.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150608201835.GM3525@orkuz.home> Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jiri Denemark Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org, borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , rth@twiddle.net, Andreas =?utf-8?Q?F=C3=A4rber?= , Eduardo Habkost On Mon, Jun 08, 2015 at 10:18:35PM +0200, Jiri Denemark wrote: > 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 meanwhile, always wanted the full CPU config data in libvirt, so that we could ensure libvirt was able to use the exact same CPU model setup on other hypervisors too - eg Xen, VMWare let us specify the CPUID masks so we could re-use the libvirt data there. > I will summarize my ideas on how libvirt should be using -cpu custom and > send them to libvirt-list soon. These patches are x86 obviously - is there anything we need to worry about for non-x86 architectures I wonder ? IIRC, all the non-x86 archs have traditionally only needed CPU model names and don't really have the same level of per-flag CPUID mask configurability that x86 has. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|