From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBmzC-0004Mo-Bw for qemu-devel@nongnu.org; Sun, 25 Mar 2012 08:55:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBmzA-00066R-CQ for qemu-devel@nongnu.org; Sun, 25 Mar 2012 08:55:53 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:58820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBmzA-00066J-6x for qemu-devel@nongnu.org; Sun, 25 Mar 2012 08:55:52 -0400 Received: by obbwd20 with SMTP id wd20so4703692obb.4 for ; Sun, 25 Mar 2012 05:55:49 -0700 (PDT) Message-ID: <4F6F15D2.8000504@codemonkey.ws> Date: Sun, 25 Mar 2012 07:55:46 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20120311124116.GI17882@redhat.com> <4F5CB3D1.4050100@codemonkey.ws> <20120311151246.GL17882@redhat.com> <4F5CC7AC.6080703@codemonkey.ws> <20120312130810.GB20654@otherpad.lan.raisama.net> <20120313145319.GD25451@otherpad.lan.raisama.net> <20120322093244.GE22368@redhat.com> <4F6B5553.20601@codemonkey.ws> <20120322171445.GJ25451@otherpad.lan.raisama.net> <4F6B850D.9000505@codemonkey.ws> <20120325094920.GJ22368@redhat.com> In-Reply-To: <20120325094920.GJ22368@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 , Eduardo Habkost , Avi Kivity , qemu-devel@nongnu.org On 03/25/2012 04:49 AM, Gleb Natapov wrote: > On Thu, Mar 22, 2012 at 03:01:17PM -0500, Anthony Liguori wrote: >> So let's avoid that and start by having a positive configuration >> mechanism that the user can use to change the path and exclude it. >> My suggestion eliminate the need for two future command line >> options. >> > If cpu models are not part of configuration they should not be affected > by configuration mechanism. You are just avoiding addressing the real > question that if asked above. I think you're just refusing to listen. The stated direction of QEMU, for literally years now, is that we want to arrive at the following: QEMU is composed of a series of objects who's relationships can be fully described by an external configuration file. Much of the current baked in concepts (like machines) would then become configuration files. qemu -M pc Would effectively be short hand for -readconfig /usr/share/qemu/machines/pc.cfg There are some valid points that were raised in this thread, namely that the user needs to have a file that acts as strictly config (stored in /etc). I'm totally happy moving the CPU configuration to /usr/share in order to address this. I think the thread has reduced to: should /usr/share configuration files be read by default or just treated as additional configuration files. It seems pretty obvious to me that they should be treated as normal configuration files. This gives you the user the ability to have fine grain control over which files are used including the ability to change the location for each file. Maybe RHEL only wants to expose supported CPUs and supported machines, wouldn't it be better to not have to patch QEMU to do that? Wouldn't it be even better if you could drop in a separate CPU configuration file with the supported CPU types and then change the default /etc config to use that instead? Regards, Anthony Liguori