From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBnSZ-0005m8-KK for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:26:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBnSW-0003Ii-On for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:26:15 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:41822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBnSW-0003IO-Jj for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:26:12 -0400 Received: by obbwd20 with SMTP id wd20so4725815obb.4 for ; Sun, 25 Mar 2012 06:26:11 -0700 (PDT) Message-ID: <4F6F1CF0.1040003@codemonkey.ws> Date: Sun, 25 Mar 2012 08:26:08 -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> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <4F6F1BE2.6040002@redhat.com> In-Reply-To: <4F6F1BE2.6040002@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: Avi Kivity Cc: Gleb Natapov , libvir-list@redhat.com, qemu-devel@nongnu.org, Jiri Denemark , "arch@ovirt.org" On 03/25/2012 08:21 AM, Avi Kivity wrote: > On 03/11/2012 04:12 PM, Anthony Liguori wrote: >> This discussion isn't about whether QEMU should have a Westmere >> processor definition. In fact, I think I already applied that patch. >> >> It's a discussion about how we handle this up and down the stack. >> >> The question is who should define and manage CPU compatibility. Right >> now QEMU does to a certain degree, libvirt discards this and does it's >> own thing, and VDSM/ovirt-engine assume that we're providing something >> and has built a UI around it. >> >> What I'm proposing we consider: have VDSM manage CPU definitions in >> order to provide a specific user experience in ovirt-engine. >> >> 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. 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. Regards, Anthony Liguori >