From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7hy6-00089C-MC for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:31:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7hy3-0006XF-GK for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:31:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7hy3-0006X1-8g for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:31:43 -0400 Date: Wed, 24 Jun 2015 12:31:38 +0200 From: "Michael S. Tsirkin" Message-ID: <20150624122248-mutt-send-email-mst@redhat.com> References: <558951C0.3050806@suse.de> <20150623150828.GD3134@thinpad.lan.raisama.net> <20150623173048-mutt-send-email-mst@redhat.com> <20150623155832.GE3134@thinpad.lan.raisama.net> <55898637.6080804@suse.de> <20150623162555.GL30318@redhat.com> <20150623183115-mutt-send-email-mst@redhat.com> <20150623164204.GM30318@redhat.com> <20150623231818-mutt-send-email-mst@redhat.com> <20150624085209.GA25601@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150624085209.GA25601@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: "Daniel P. Berrange" 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 =?iso-8859-1?Q?F=E4rber?= , Eduardo Habkost On Wed, Jun 24, 2015 at 09:52:09AM +0100, Daniel P. Berrange wrote: > On Tue, Jun 23, 2015 at 11:23:16PM +0200, Michael S. Tsirkin wrote: > > > > So any single CPU flag now needs to be added in > > - kvm > > - qemu > > - libvirt > > This is in fact already the case, and it will also possibly need > to be added to openstack too. > > > Next thing libvirt will decide it's a policy thing and so > > needs to be pushed up to openstack. > > In fact openstack would really like it if we did exactly that, but > even just having CPUs versioned separately from machine types would > be a big step forward as far as openstack is concerned. > > The openstack schedular does not have full visibility into the way > the guest is going to be configured by libvirt/QEMU, in particular > it does not know anything about machine type that will be used by > the guest. > > The compute hosts report what CPU features they can support, and > the user / admin will be able to express what CPU model and/or > features they desire their guest to run with, and the schedular > has to match that up to decide on hosts to use. If the CPU QEMU > machine type used can alter what the CPU model means in terms > of features, then the schedling decisions OpenStack is making > are going to be wrong some portion of the time. Is this all just theoretical, or are there real examples where things stop running? I keep hearing "feature xyz" and it's impossible to argue reasonably about that IMHO. > So from the POV of the OpenStack schedular, we'd much rather > have CPU models versioned explicitly so their semantics do not > change behind our back based on machine types. > > OpenStack is also looking at how to present a consistent > description of CPU models to users, which is independant of > the cloud. Since libvirt/QEMU doesn't allow 100% control of > the CPU model, OpenStack is likely going to have to define > some kind of manual mapping of its own. > > > We should just figure out what you want to do and support it in QEMU. > > Main thing is versioned CPU models with fixed semantics that > don't magically change based on other aspects of VM configuration, > such as the machine type. This could be accomplished by QEMU > alone. > > Following on from that though, there's two other aspects which > we'd like to address. First, be able to present a consistent > set of CPU models across all hypervisors libvirt manages, > regardless of type or version. This is a key reason why we have > always maintained our own CPU model database, even though it > duplicates QEMU's. Do you also want to migrate that? If yes, the problem definitely becomes more than just CPU specific. > More interesting is the question of host passthrough. We have > two modes for that - either 'host-model' or 'host-passthrough'. > The 'host-passthrough' option is something that explicitly > maps to QEMU's '-cpu host'. This is good because it exposes > 100% of the host CPU to the guest. This is bad because it then > prevents use of migration in general, unless both machines > are 100% identical - libvirt just blocks it rather than trying > todo such a fine grained host CPU check. > > For that reason we have 'host-model', which is supposed to be > essentially the same thing instead of '-cpu host' we explicitly > list all the features alongside a named model. Since we control > exactly what the guest is being given, we can permit guests > with 'host-model' to be migrated, even if the destination host > is a superset of the source host, we know the guest won't > suddenly see a model change after migration. Currently we are > limited though, as we can only express the CPU features - we > cannot expose the other aspects like level, xlevel, etc. So > our 'host-model' is not quite as perfect a match as '-cpu host' > is. The '-cpu custom' would help us getting a better match > for 'host-model' by allowing these extra things to be configured. This duplicates code from QEMU though. It looks like we need a tool to get the legal CPUs that can run on the given host? Would be easy to add, reusing QEMU codebase. Maybe make it a new QEMU flag. > > Are there many examples where a single flag used to work and then > > stopped? I would say such a change is problematic anyway: > > not everyone uses libvirt, you are breaking things for people > > that run -M pc. > > > > IMHO -M pc is not supposed to mean "can break at any time". > > Well 'pc' is an unversioned machine type, so it explicitly is said to > break at any time - users/apps are supposed to translate that into a > versioned type if they want a guarantee of no breakage. > > Regards, > Daniel That's because you are looking at it from libvirt perspective. From QEMU command line, since pc is the default, this makes no sense IMHO: look up usage advice on the internet, and you will see no one specifies a machine type. > -- > |: 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 :|