From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6i5Z-000515-7C for qemu-devel@nongnu.org; Sun, 11 Mar 2012 08:41:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6i5W-0003Xh-OM for qemu-devel@nongnu.org; Sun, 11 Mar 2012 08:41:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6i5W-0003XY-G6 for qemu-devel@nongnu.org; Sun, 11 Mar 2012 08:41:26 -0400 Date: Sun, 11 Mar 2012 14:41:16 +0200 From: Gleb Natapov Message-ID: <20120311124116.GI17882@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120310155843.GJ2914@otherpad.lan.raisama.net> 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: "Daniel P. Berrange" , libvir-list@redhat.com, qemu-devel@nongnu.org, Anthony Liguori , Jiri Denemark , Avi Kivity On Sat, Mar 10, 2012 at 12:58:43PM -0300, Eduardo Habkost wrote: > On Sat, Mar 10, 2012 at 12:42:46PM +0000, Daniel P. Berrange wrote: > > > > > > I could have sworn we had this discussion a year ago or so, and had decided > > > that the default CPU models would be in something like /usr/share/qemu/cpu-x86_64.conf > > > and loaded regardless of the -nodefconfig setting. /etc/qemu/target-x86_64.conf > > > would be solely for end user configuration changes, not for QEMU builtin > > > defaults. > > > > > > But looking at the code in QEMU, it doesn't seem we ever implemented this ? > > > > Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu RPMs but, > > contrary to our normal RHEL development practice, it was not based on > > a cherry-pick of an upstream patch :-( > > > > For sake of reference, I'm attaching the two patches from the RHEL6 source > > RPM that do what I'm describing > > > > NB, I'm not neccessarily advocating these patches for upstream. I still > > maintain that libvirt should write out a config file containing the > > exact CPU model description it desires and specify that with -readconfig. > > The end result would be identical from QEMU's POV and it would avoid > > playing games with QEMU's config loading code. > > I agree that libvirt should just write the config somewhere. The problem > here is to define: 1) what information should be mandatory on that > config data; 2) who should be responsible to test and maintain sane > defaults (and where should they be maintained). > > The current cpudef definitions are simply too low-level to require it to > be written from scratch. Lots of testing have to be done to make sure we > have working combinations of CPUID bits defined, so they can be used as > defaults or templates. Not facilitating reuse of those tested > defauls/templates by libvirt is duplication of efforts. > > Really, if we expect libvirt to define all the CPU bits from scratch on > a config file, we could as well just expect libvirt to open /dev/kvm > itself and call the all CPUID setup ioctl()s itself. That's how > low-level some of the cpudef bits are. > s/some/all If libvirt assumes anything about what kvm actually supports it is working only by sheer luck. > (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. > > (And I really hope that there's no plan to require all those low-level > bits to appear as-is on the libvirt XML definitions. Because that would > require users to read the Intel 64 and IA-32 Architectures Software > Developer's Manual, or the AMD64 Architecture Programmer's Manual and > BIOS and Kernel Developer's Guides, just to understand why something is > not working on his Virtual Machine.) > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=689665 > > -- > Eduardo -- Gleb.