From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMsbz-0004q2-BG for qemu-devel@nongnu.org; Mon, 21 Dec 2009 19:28:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMsbu-0004m5-K8 for qemu-devel@nongnu.org; Mon, 21 Dec 2009 19:28:27 -0500 Received: from [199.232.76.173] (port=34078 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMsbu-0004lp-ET for qemu-devel@nongnu.org; Mon, 21 Dec 2009 19:28:22 -0500 Received: from dpc6682208002.direcpc.com ([66.82.208.2]:56908 helo=anvil.third-harmonic.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NMsbq-0003aM-G8 for qemu-devel@nongnu.org; Mon, 21 Dec 2009 19:28:22 -0500 Message-ID: <4B2FFBE1.50502@third-harmonic.com> Date: Mon, 21 Dec 2009 17:51:13 -0500 From: john cooper MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <4B2DF334.6030208@redhat.com> <20091220155101.GB31257@redhat.com> <4B2E49E5.6050709@redhat.com> <20091220165612.GC31257@redhat.com> <20091220171822.GD31257@redhat.com> <20091220172341.GB21163@redhat.com> <2162E312-0110-42E1-A391-D75A6F013554@suse.de> <20091220173702.GC21163@redhat.com> <4B2E660F.1050703@codemonkey.ws> <20091221074355.GU4490@redhat.com> <4B2F31B1.6040403@redhat.com> In-Reply-To: <4B2F31B1.6040403@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: Gleb Natapov , "Michael S. Tsirkin" , John Cooper , Alexander Graf , qemu-devel@nongnu.org, Avi Kivity Dor Laor wrote: > Qemu will check the required cpuid of the cpu model on the host and > refuse to load otherwise. When moving to this model, migration can be > simplified too since there are fewer combination, and one can choose > performance over migration flexibility and wise versa. > Due to the above check, the destination qemu won't load if the host does > not support its cpu model. If you're referring to the check in my patch, that's currently advisory only. The existing cpu model encoding of CPUID tosses flags in to the soup on speculation they may be available on the host. If not it assumes they will be quietly disabled on their way to the guest along with whatever flags were enabled via + on the command line. This mixed treatment for model implied vs. user specified flags could be partly an artifact of trying to adapt the legacy qemu64 model to whatever host silicon it finds itself upon. -john -- john.cooper@third-harmonic.com