From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6hDm-00062b-El for qemu-devel@nongnu.org; Sun, 11 Mar 2012 07:45:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6hDk-0002SX-IJ for qemu-devel@nongnu.org; Sun, 11 Mar 2012 07:45:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14781) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6hDk-0002SM-9S for qemu-devel@nongnu.org; Sun, 11 Mar 2012 07:45:52 -0400 Date: Sun, 11 Mar 2012 13:45:42 +0200 From: Gleb Natapov Message-ID: <20120311114542.GG17882@redhat.com> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <4F5A72EE.9030905@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F5A72EE.9030905@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 Fri, Mar 09, 2012 at 03:15:26PM -0600, Anthony Liguori wrote: > On 03/09/2012 03:04 PM, Daniel P. Berrange wrote: > >On Fri, Mar 09, 2012 at 05:56:52PM -0300, Eduardo Habkost wrote: > >>Resurrecting an old thread: > >> > >>I didn't see any clear conclusion in this thread (this is why I am > >>resurrecting it), except that many were arguing that libvirt should > >>simply copy and/or generate the CPU model definitions from Qemu. I > >>really don't think it's reasonable to expect that. > >> > >>On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote: > >>>Hi, > >>> > >>>Recently I realized that all modern CPU models defined in > >>>/etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. > >>>That's because we start qemu with -nodefconfig which results in qemu ignoring > >>>that file with CPU model definitions. We have a very good reason for using > >>>-nodefconfig because we need to control the ABI presented to a guest OS and we > >>>don't want any configuration file that can contain lots of things including > >>>device definitions to be read by qemu. However, we would really like the new > >>>CPU models to be understood by qemu even if used through libvirt. What would > >>>be the best way to solve this? > >>> > >>>I suspect this could have been already discussed in the past but obviously a > >>>workable solution was either not found or just not implemented. > >> > >>So, our problem today is basically: > >> > >>A) libvirt uses -nodefconfig; > >>B) -nodefconfig makes Qemu not load the config file containing the CPU > >> model definitions; and > >>C) libvirt expects the full CPU model list from Qemu to be available. > > > >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 ? > > I don't remember that discussion and really don't think I agree with the conclusion. > > If libvirt wants to define CPU models on their own, they can. If It can't without knowing qemu/host cpu/host kernel capabilities and knowing the logic that qemu uses to combine them. > libvirt wants to use the user's definitions, don't use -nodefconfig. > > CPU models aren't a QEMU concept. The reason it's in the I do not know what do you mean by that, but CPU capabilities (and CPU model is only a name for a group of them) are KVM/TCG concept and, by inclusion, are QEMU concept. If QEMU will not have built in support for CPU models (as a name for a group of CPU capabilities) then how do you start a guest without specifying full set of CPU capabilities on a command line? > configuration file is to allow a user to add their own as they see > fit. There is no right model names. It's strictly a policy. > So you think it should be user's responsibility to check what his qemu/host cpu/host kernel combo can support? -- Gleb.