From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6kSB-0007kj-Cn for qemu-devel@nongnu.org; Sun, 11 Mar 2012 11:13:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6kS9-0006pX-J8 for qemu-devel@nongnu.org; Sun, 11 Mar 2012 11:12:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6kS9-0006pR-AP for qemu-devel@nongnu.org; Sun, 11 Mar 2012 11:12:57 -0400 Date: Sun, 11 Mar 2012 17:12:47 +0200 From: Gleb Natapov Message-ID: <20120311151246.GL17882@redhat.com> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <20120311124116.GI17882@redhat.com> <4F5CB3D1.4050100@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F5CB3D1.4050100@codemonkey.ws> Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: libvir-list@redhat.com, Jiri Denemark , qemu-devel@nongnu.org, Avi Kivity On Sun, Mar 11, 2012 at 09:16:49AM -0500, Anthony Liguori wrote: > >If libvirt assumes anything about what kvm actually supports it is > >working only by sheer luck. > > Well the simple answer for libvirt is don't use -nodefconfig and > then it can reuse the CPU definitions (including any that the user > adds). CPU models should be usable even with -nodefconfig. CPU model is more like device. By -cpu Nehalem I am saying I want Nehalem device in my machine. > > Really, what's the point of having a layer of management if we're > saying that doing policy management is too complicated for that > layer? What does that layer exist to provide then? > I was always against libvirt configuring low level details of CPU. What it should do IMO is to chose best CPU model for host cpu (one can argue that fiddling with /proc/cpuinfo is not QEMU busyness). > >>(Also, there are additional low-level bits that really have to be > >>maintained somewhere, just to have sane defaults. Currently many CPUID > >>leafs are exposed to the guest without letting the user control them, > >>and worse: without keeping stability of guest-visible bits when > >>upgrading Qemu or the host kernel. And that's what machine-types are > >>for: to have sane defaults to be used as base.) > >> > >>Let me give you a practical example: I had a bug report about improper > >>CPU topology information[1]. After investigating it, I have found out > >>that the "level" cpudef field is too low; CPU core topology information > >>is provided on CPUID leaf 4, and most of the Intel CPU models on Qemu > >>have level=2 today (I don't know why). So, Qemu is responsible for > >>exposing CPU topology information set using '-smp' to the guest OS, but > >>libvirt would have to be responsible for choosing a proper "level" value > >>that makes that information visible to the guest. We can _allow_ libvirt > >>to fiddle with these low-level bits, of course, but requiring every > >>management layer to build this low-level information from scratch is > >>just a recipe to waste developer time. > >And QEMU become even less usable from a command line. One more point to > >kvm-tool I guess. > > I'm not sure what your point is. We're talking about an option that > humans don't use. How is this a discussion about QEMU usability? > If for a user to have stable guest environment we require libvirt use then QEMU by itself is less usable. We do have machine types in QEMU to expose stable machine to a guest. CPU models should be part of it. -- Gleb.