From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7hok-0005Qs-Mz for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:22:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7hog-0001Lb-Lb for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:22:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39400) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7hog-0001LX-Eg for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:22:02 -0400 Date: Wed, 24 Jun 2015 12:21:57 +0200 From: "Michael S. Tsirkin" Message-ID: <20150624121700-mutt-send-email-mst@redhat.com> References: <1433790460-30679-1-git-send-email-ehabkost@redhat.com> <20150608201835.GM3525@orkuz.home> <558951C0.3050806@suse.de> <20150624092050.GA118757@orkuz.home> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20150624092050.GA118757@orkuz.home> 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: Jiri Denemark Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , rth@twiddle.net, Andreas =?iso-8859-1?Q?F=E4rber?= , Eduardo Habkost On Wed, Jun 24, 2015 at 11:20:50AM +0200, Jiri Denemark wrote: > 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 = provided, > > >> that will generate a config file that can be loaded using -readcon= fig, 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 th= e CPU > > > configuration data to libvirt, but now I think it actually makes se= nse. > > > 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 CP= U > > > 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 = not > > have a stable ABI for x86 CPUs? That's what we have the pc*-x.y machi= nes > > for. >=20 > 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" include= s > 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. Are there really many examples like this? Could someone supply some examples? Eduardo gave examples of CPU changes across machine types but I haven't seen examples where we would break runnability. > 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. >=20 > 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 o= f > a CPU model and a machine type without actually having to start > QEMU with each CPU and a machine type separately >=20 > 2. manage CPU models in libvirt (aka -cpu custom) >=20 > During the past several years Eduardo tried to do (1) without getting > anywhere close to something that QEMU would be willing to accept. And the reason, presumably, is because it's a hard problem to solve. Why is it easier to solve at the libvirt level? > 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). >=20 > Jirka I'm fine with the change itself, it's useful e.g. for testing. But how is it a solution for libvirt's problems? What is libvirt going to do in the above cases? --=20 MST