From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUT2b-0005M0-19 for qemu-devel@nongnu.org; Tue, 03 Feb 2009 16:42:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUT2Z-0005Kq-80 for qemu-devel@nongnu.org; Tue, 03 Feb 2009 16:42:44 -0500 Received: from [199.232.76.173] (port=57078 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUT2Z-0005Kg-30 for qemu-devel@nongnu.org; Tue, 03 Feb 2009 16:42:43 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.144]:60667) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LUT2Y-00022H-Mg for qemu-devel@nongnu.org; Tue, 03 Feb 2009 16:42:42 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n13LemZ4028115 for ; Tue, 3 Feb 2009 16:40:48 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n13LgfQC166742 for ; Tue, 3 Feb 2009 16:42:41 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n13LgfFj021608 for ; Tue, 3 Feb 2009 16:42:41 -0500 Message-ID: <4988BA3F.5030605@us.ibm.com> Date: Tue, 03 Feb 2009 15:42:23 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] don't expose lm bit if kernel is not 64-bit capable. References: <1233673454-14526-1-git-send-email-glommer@redhat.com> <49889CEB.7060602@redhat.com> <5d6222a80902031200i5b46b536vd2a95089d48a098e@mail.gmail.com> <4988B39B.5050509@us.ibm.com> <5d6222a80902031335l41c90b98y36b0b0f76c6d8987@mail.gmail.com> In-Reply-To: <5d6222a80902031335l41c90b98y36b0b0f76c6d8987@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: qemu-devel@nongnu.org Glauber Costa wrote: > On Tue, Feb 3, 2009 at 7:14 PM, Anthony Liguori wrote: > >> >> All I said was that if we used KVM_GET_SUPPORTED_CPUID, we had to do >> something about save/restore since it can mask arbitrary things. >> >> > Then I misread you. > > Who's the subject of your sentence, that can mask arbitrary things? > kvm.ko in its ioctl, > or save/restore? > Poor wording on my part. Your previous patch called KVM_GET_SUPPORTED_CPUID which would return the host CPUID bits that KVM supports. QEMU would then use that set to mask out features for the guest. But the set of bits KVM returns differs on differing platforms. This means that you're now enabling features that were not previously enabled. This isn't a problem, but I'd like to see live migration handle this gracefully either by saving off the CPUID bits for the guest and failing appropriately when trying to enable CPUID bits on a platform that doesn't support it, or an explicit definition of CPUID capabilities. I don't necessarily have a problem with enabling the most features by default, I just want migration to fail gracefully. Regards, Anthony Liguori