From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6jaD-0004qv-PN for qemu-devel@nongnu.org; Sun, 11 Mar 2012 10:17:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6jZt-0006Gf-DJ for qemu-devel@nongnu.org; Sun, 11 Mar 2012 10:17:13 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:43968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6jZt-0006GF-84 for qemu-devel@nongnu.org; Sun, 11 Mar 2012 10:16:53 -0400 Received: by ghrr14 with SMTP id r14so2225504ghr.4 for ; Sun, 11 Mar 2012 07:16:51 -0700 (PDT) Message-ID: <4F5CB3D1.4050100@codemonkey.ws> Date: Sun, 11 Mar 2012 09:16:49 -0500 From: Anthony Liguori MIME-Version: 1.0 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> In-Reply-To: <20120311124116.GI17882@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Gleb Natapov Cc: libvir-list@redhat.com, Jiri Denemark , qemu-devel@nongnu.org, Avi Kivity On 03/11/2012 07:41 AM, Gleb Natapov wrote: > 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. 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). 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? >> (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? Regards, Anthony Liguori