From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7grZ-0007Pl-9N for qemu-devel@nongnu.org; Wed, 24 Jun 2015 05:20:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7grW-0004lo-3j for qemu-devel@nongnu.org; Wed, 24 Jun 2015 05:20:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53523) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7grV-0004lO-Fz for qemu-devel@nongnu.org; Wed, 24 Jun 2015 05:20:53 -0400 Date: Wed, 24 Jun 2015 11:20:50 +0200 From: Jiri Denemark Message-ID: <20150624092050.GA118757@orkuz.home> References: <1433790460-30679-1-git-send-email-ehabkost@redhat.com> <20150608201835.GM3525@orkuz.home> <558951C0.3050806@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <558951C0.3050806@suse.de> Content-Transfer-Encoding: quoted-printable 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: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: mimu@linux.vnet.ibm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , rth@twiddle.net, Eduardo Habkost On Tue, Jun 23, 2015 at 14:32:00 +0200, Andreas F=E4rber wrote: > Am 08.06.2015 um 22:18 schrieb Jiri Denemark: > >> To help libvirt in the transition, a x86-cpu-model-dump script is pr= ovided, > >> that will generate a config file that can be loaded using -readconfi= g, based on > >> the -cpu and -machine options provided in the command-line. > >=20 > > 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 sens= e. > > We already have a partial copy of CPU model definitions in libvirt > > anyway, but as QEMU changes some CPU models in some machine types (an= d > > 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. >=20 > That sounds like FUD to me. Any concrete data points where QEMU does no= t > have a stable ABI for x86 CPUs? That's what we have the pc*-x.y machine= s > for. QEMU provides stable ABI for x86 CPUs only if you use -cpu ...,enforce. Without enforce the CPU may change everytime a domain is started or migrated. A small example: let's say a CPU model called "Model" includes feature "xyz"; when QEMU is started with -cpu Model (no enforce) on a host which supports xyz, the guest OS will see a CPU with xyz, but when you migrate it to a host which does not support xyz, QEMU will just silently drop xyz. In other words, we need to use enforce to make sure CPU ABI does not change. But the problem is we can't use enforce because we don't know how a specific CPU model looks like for a given machine type. Remember, while libvirt allows users to explicitly ask for a specific CPU model and features, it also has a mode when libvirt itself computes the right CPU model and features. And this is impossible with enforce without us knowing all details about CPU models. So there are two possible ways to address this: 1. enhance QEMU to give us all we need - either by providing commands that would do all the computations (CPU model comparison, intersections or denominator, something like -cpu best) - or provide a way to probe for all (currently 700+) combinations of a CPU model and a machine type without actually having to start QEMU with each CPU and a machine type separately 2. manage CPU models in libvirt (aka -cpu custom) During the past several years Eduardo tried to do (1) without getting anywhere close to something that QEMU would be willing to accept. On the other hand (2) is a pretty minimal change to QEMU and is more flexible than (1) because it allows CPU model versions to be decoupled from machine types (but this was already discussed a lot in the other emails in this thread). Jirka