From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/2] Allow the SVM CPUID bit in a VM Date: Wed, 03 Sep 2008 12:19:44 +0300 Message-ID: <48BE56B0.5080001@qumranet.com> References: <1220270342-15769-1-git-send-email-agraf@suse.de> <1220270342-15769-2-git-send-email-agraf@suse.de> <1220270342-15769-3-git-send-email-agraf@suse.de> <48BBF570.9070301@qumranet.com> <4EE967D1-3CB5-45C4-B480-0D230242D476@suse.de> <484561CE-F0E6-45E9-BBF0-7DBDB8571873@suse.de> <48BE42F8.3040902@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gerd Hoffmann , kvm@vger.kernel.org, joro@8bytes.org, anthony@codemonkey.ws To: Alexander Graf Return-path: Received: from il.qumranet.com ([212.179.150.194]:42490 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751140AbYICJTq (ORCPT ); Wed, 3 Sep 2008 05:19:46 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Alexander Graf wrote: > > I guess I didn't express myself correctly, sorry for that :-). I think > that kvm kernel module capabilities should be masked out in the kernel > module, while "other" stuff, like migration masking or additional > CPUIDs (do these work atm?) should of course reside in the userspace. But then userspace needs to know when capabilities userspace actually sees. > > The code I was referring to was the removal of the NX bit and the SVM > bit. These are definitely kernel capabilities. If the kernel module > doesn't implement these, it should just mask them out instead of > having userspace figure out what's there and what isn't. The flow I have in mind is: - kernel exports which cpuid bits it supports (global information; not tied to a guest; this way it can be used to calculate g-c-d) - userspace merges this information with its own ideas - userspace tells the kernel what cpuid bits to present to the guest (lying is allowed) This gives the maximum flexibility and visibility. NX and SVM are masked for backward compatibility with older userspace; we could probably remove this masking now. > > I hope I didn't completely confuse everybody now :-). On a sidenote: > We really need to switch to the newer cpuid kernel<->userspace > interface. The way it currently is, CPUID 4 is severely broken. There is a new interface in place (quite old by now), unfortunately it isn't used by qemu. -- error compiling committee.c: too many arguments to function