From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSsd8-0002QP-6Z for qemu-devel@nongnu.org; Fri, 30 Jan 2009 07:37:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSsd5-0002PB-5W for qemu-devel@nongnu.org; Fri, 30 Jan 2009 07:37:52 -0500 Received: from [199.232.76.173] (port=40552 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSsd4-0002Ot-03 for qemu-devel@nongnu.org; Fri, 30 Jan 2009 07:37:50 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:36554) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LSsd3-0007J4-Kh for qemu-devel@nongnu.org; Fri, 30 Jan 2009 07:37:49 -0500 Received: by qyk13 with SMTP id 13so770019qyk.10 for ; Fri, 30 Jan 2009 04:37:46 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <498216B0.9030400@us.ibm.com> References: <1233249569-16686-1-git-send-email-glommer@redhat.com> <1233249569-16686-2-git-send-email-glommer@redhat.com> <1233249569-16686-3-git-send-email-glommer@redhat.com> <1233249569-16686-4-git-send-email-glommer@redhat.com> <498216B0.9030400@us.ibm.com> Date: Fri, 30 Jan 2009 10:37:45 -0200 Message-ID: <5d6222a80901300437y2dde03dak2c9a91f8a1783730@mail.gmail.com> Subject: Re: [Qemu-devel] Re: [PATCH 3/4] mask out forbidden cpuid features with kvm ioctl From: Glauber Costa Content-Type: text/plain; charset=UTF-8 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: qemu-devel@nongnu.org Cc: Glauber Costa , Anthony Liguori On Thu, Jan 29, 2009 at 6:50 PM, Anthony Liguori wrote: > Glauber Costa wrote: >> >> KVM has a (so far unused) ioctl to inform userspace >> about supported cpuid bits in the current host. >> >> The lack of this kind of checking can lead to bugs in which >> a cpuid bit is exposed but not supported by the host kernel >> (an example is fedora bug >> https://bugzilla.redhat.com/show_bug.cgi?id=481274) >> >> The current host_cpuid code is replaced by this general check. >> >> Signed-off-by: Glauber Costa >> > > So what do we do about live migration? Does KVM mask a set of bits > unconditionally? Before, we were masking unconditionally which should > insulate migration reasonable well. > Just to be clear: Are you raising the flag against the lack of unconditional mask only, or about it + querying kvm.ko for supported bits? I think we need to query it anyway, because calling cpuid will only give you information about your cpu, and querying the kernel will give you this, plus information about what the kernel supports (think of the 32 bit kernel on 64 bit hardware case), plus whatever else kvm wants to mask for whatever reason. About migration, I was under the impression that the solution we were going towards was based on defining a kvm machine type that would contain a common set of features among the hosts involved. If this is the case, I believe we don't need to unconditionally mask out anything, since the features we expose in the machine type won't even have the problematic features. If this is not the case, I'm fine with redoing this patch with querying kvm.ko + unconditional mask of potentially problematic features. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."