From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7hy6-00089B-M2 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:31:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7hy3-0006XA-Fd for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:31:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7hy3-0006X0-91 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:31:43 -0400 Date: Wed, 24 Jun 2015 11:31:37 +0100 From: "Daniel P. Berrange" Message-ID: <20150624103136.GC25601@redhat.com> References: <1433790460-30679-1-git-send-email-ehabkost@redhat.com> <20150608201835.GM3525@orkuz.home> <558951C0.3050806@suse.de> <20150624092050.GA118757@orkuz.home> <20150624121700-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150624121700-mutt-send-email-mst@redhat.com> Content-Transfer-Encoding: quoted-printable 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: "Michael S. Tsirkin" Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , rth@twiddle.net, Andreas =?utf-8?Q?F=C3=A4rber?= , Eduardo Habkost On Wed, Jun 24, 2015 at 12:21:57PM +0200, Michael S. Tsirkin wrote: > 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=C3=A4rber wrote: > > > Am 08.06.2015 um 22:18 schrieb Jiri Denemark: > > > >> To help libvirt in the transition, a x86-cpu-model-dump script i= s provided, > > > >> that will generate a config file that can be loaded using -readc= onfig, 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 = sense. > > > > We already have a partial copy of CPU model definitions in libvir= t > > > > 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 enfor= ce > > > > stable guest ABI. > > >=20 > > > That sounds like FUD to me. Any concrete data points where QEMU doe= s not > > > have a stable ABI for x86 CPUs? That's what we have the pc*-x.y mac= hines > > > for. > >=20 > > QEMU provides stable ABI for x86 CPUs only if you use -cpu ...,enforc= e. > > Without enforce the CPU may change everytime a domain is started or > > migrated. A small example: let's say a CPU model called "Model" inclu= des > > 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 wh= en > > 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 sur= e > > CPU ABI does not change. >=20 > 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. >=20 > > 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, whi= le > > libvirt allows users to explicitly ask for a specific CPU model and > > features, it also has a mode when libvirt itself computes the right C= PU > > 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= of > > 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. >=20 > And the reason, presumably, is because it's a hard problem to solve. > Why is it easier to solve at the libvirt level? One of the main reasons it is hard is because QEMU machine types are not statically introspectable - you have to actually instantiate the machine type to determine what config it produces. This is ultimately a limitation of QOM, and while it could be fixed it would be a pretty significant design change for QEMU at this point. So the reason it would be simpler in libvirt is that we would not have any need to attempt such introspection - the data we need would immediately available to libvirt in the format it needs to use it in. The OpenStack scheduling example I mentioned elsewhere is another reason where the current scheme causes pain - the point at which OpenStack wants to make decisions about host/guest CPU compatibility, we don't even have a guest configuration available yet, so we don't know what machine type we'd want to use, and QEMU isn't even installed on the hosts doing this decision making. Currently OpenStack just has to pretend that CPU models don't change based on machine type. Most of the time we'll be lucky and that won't hurt us, but obviously it is not a desirable thing to have todo. > > On the > > other hand (2) is a pretty minimal change to QEMU and is more flexibl= e > > than (1) because it allows CPU model versions to be decoupled from > > machine types (but this was already discussed a lot in the other emai= ls > > in this thread). > >=20 > > Jirka >=20 > I'm fine with the change itself, it's useful e.g. for testing. >=20 > But how is it a solution for libvirt's problems? > What is libvirt going to do in the above cases? Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|