From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NN5Bp-0006Zf-Ed for qemu-devel@nongnu.org; Tue, 22 Dec 2009 08:54:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NN5Bl-0006Xx-Tb for qemu-devel@nongnu.org; Tue, 22 Dec 2009 08:54:17 -0500 Received: from [199.232.76.173] (port=48028 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NN5Bl-0006Xu-PT for qemu-devel@nongnu.org; Tue, 22 Dec 2009 08:54:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41968) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NN5Bl-0002rG-JX for qemu-devel@nongnu.org; Tue, 22 Dec 2009 08:54:13 -0500 Message-ID: <4B30CF92.50509@redhat.com> Date: Tue, 22 Dec 2009 15:54:26 +0200 From: Dor Laor 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> <4B2FFBE1.50502@third-harmonic.com> In-Reply-To: <4B2FFBE1.50502@third-harmonic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: john cooper Cc: Gleb Natapov , "Michael S. Tsirkin" , John Cooper , Alexander Graf , qemu-devel@nongnu.org, Avi Kivity On 12/22/2009 12:51 AM, john cooper wrote: > 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 why not shout loudly and abort? Do you want windows to reactivate itself? > 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 > >