From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBnPU-0004nY-Gv for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:23:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBnPS-0002uM-Dn for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:23:04 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:60450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBnPS-0002uG-8a for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:23:02 -0400 Received: by obbwd20 with SMTP id wd20so4723612obb.4 for ; Sun, 25 Mar 2012 06:23:00 -0700 (PDT) Message-ID: <4F6F1C32.7090801@codemonkey.ws> Date: Sun, 25 Mar 2012 08:22:58 -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> <4F6F19AC.1080009@codemonkey.ws> <4F6F1A50.5090502@redhat.com> In-Reply-To: <4F6F1A50.5090502@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:14 AM, Avi Kivity wrote: > On 03/25/2012 03:12 PM, Anthony Liguori wrote: >>>> 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? > > Nope. As long as qemu -nodefconfig -cpu westmere works, I'm happy. Why? What's wrong with: qemu -nodefconfig -readconfig /usr/share/qemu/cpus/target-x86_64-cpus.cfg \ -cpu westmere And if that's not okay, would: qemu -nodefconfig -nocpudefconfig -cpu Westmere Not working be a problem? > The reasoning is, loading target-x86_64-cpus.cfg does not alter the > current instance's configuration, so reading it doesn't violate > -nodefconfig. I think we have a different view of what -nodefconfig does. We have a couple options today: -nodefconfig Don't read the default configuration files. By default, we read /etc/qemu/qemu.cfg and /etc/qemu/target-$(ARCH).cfg -nodefaults Don't create default devices. -vga none Don't create the default VGA device (not covered by -nodefaults). With these two options, the semantics you get an absolutely minimalistic instance of QEMU. Tools like libguestfs really want to create the simplest guest and do the least amount of processing so the guest runs as fast as possible. It does suck a lot that this isn't a single option. I would much prefer -nodefaults to be implied by -nodefconfig. Likewise, I would prefer that -nodefaults implied -vga none. >>>> 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 think the thread has reduced to: should /usr/share configuration >> >> I suspect libvirt would not be happy with reading configuration files >> on demand.. > > Why not? It implies a bunch of SELinux labeling to make sVirt work. libvirt tries very hard to avoid having QEMU read *any* files at all when it starts up. Regards, Anthony Liguori