From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBpyC-0005Wf-Vm for qemu-devel@nongnu.org; Sun, 25 Mar 2012 12:07:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBpyB-0006pK-6K for qemu-devel@nongnu.org; Sun, 25 Mar 2012 12:07:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBpyA-0006mR-U2 for qemu-devel@nongnu.org; Sun, 25 Mar 2012 12:07:03 -0400 Message-ID: <4F6F429C.8060202@redhat.com> Date: Sun, 25 Mar 2012 18:06:52 +0200 From: Avi Kivity 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> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <4F6F1BE2.6040002@redhat.com> <4F6F1CF0.1040003@codemonkey.ws> In-Reply-To: <4F6F1CF0.1040003@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: Gleb Natapov , libvir-list@redhat.com, qemu-devel@nongnu.org, Jiri Denemark , "arch@ovirt.org" On 03/25/2012 03:26 PM, Anthony Liguori wrote: >>> We would continue to have Westmere/etc in QEMU exposed as part of the >>> user configuration. But I don't think it makes a lot of sense to have >>> to modify QEMU any time a new CPU comes out. >> >> We have to. New features often come with new MSRs which need to be live >> migrated, and of course the cpu flags as well. We may push all these to >> qemu data files, but this is still qemu. We can't let a management tool >> decide that cpu feature X is safe to use on qemu version Y. > > > I think QEMU should own CPU definitions. Agree. > I think a management tool should have the choice of whether they are > used though because they are a policy IMHO. > > It's okay for QEMU to implement some degree of policy as long as a > management tool can override it with a different policy. Sure. We can have something like # default machine's westmere qemu -cpu westmere # pc-1.0's westmere qemu -M pc-1.0 -cpu westmere # pc-1.0's westmere, without nx-less qemu -M pc-1.0 -cpu westmere,-nx # specify everything in painful detail qemu -cpu vendor=Foo,family=17,model=19,stepping=3,maxleaf=12,+fpu,+vme,leaf10eax=0x1234567,+etc -- error compiling committee.c: too many arguments to function