From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBnF4-0008Vz-K9 for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:12:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBnF3-0000rM-0I for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:12:18 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:59584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBnF2-0000qj-RA for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:12:16 -0400 Received: by obbwd20 with SMTP id wd20so4715754obb.4 for ; Sun, 25 Mar 2012 06:12:15 -0700 (PDT) Message-ID: <4F6F19AC.1080009@codemonkey.ws> Date: Sun, 25 Mar 2012 08:12:12 -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> <4F6F15D2.8000504@codemonkey.ws> <4F6F18E4.2040905@redhat.com> In-Reply-To: <4F6F18E4.2040905@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: libvir-list@redhat.com, Jiri Denemark , Eduardo Habkost , Gleb Natapov , qemu-devel@nongnu.org On 03/25/2012 08:08 AM, Avi Kivity wrote: > On 03/25/2012 02:55 PM, Anthony Liguori wrote: >>> 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 > > In that case > > qemu -cpu westmere > > is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg. This is not a bad suggestion, although it would make -cpu ? a bit awkward. Do you see an advantage to this over having /usr/share/qemu/target-x86_64-cpus.cfg that's read early on? >> I think the thread has reduced to: should /usr/share configuration >> files be read by default or just treated as additional configuration >> files. > > If they're read as soon as they're referenced, what's the difference? I suspect libvirt would not be happy with reading configuration files on demand.. Regards, Anthony Liguori