From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wss82-0000GJ-Ov for qemu-devel@nongnu.org; Fri, 06 Jun 2014 07:16:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wss7u-0005pA-C9 for qemu-devel@nongnu.org; Fri, 06 Jun 2014 07:16:10 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33967 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wss7u-0005p2-5v for qemu-devel@nongnu.org; Fri, 06 Jun 2014 07:16:02 -0400 Message-ID: <5391A2F0.7010007@suse.de> Date: Fri, 06 Jun 2014 13:16:00 +0200 From: Alexander Graf MIME-Version: 1.0 References: <539099B6.2090000@suse.de> <53909A41.1060800@redhat.com> <53909D79.1070609@suse.de> <53909E53.9050300@redhat.com> <53909E9C.6080009@suse.de> <5390A06A.9070200@redhat.com> <5390A1A9.40602@suse.de> <20140605174801.GQ17594@otherpad.lan.raisama.net> <5390EE1A.9080503@suse.de> <20140606012104.GA27257@pd.tnic> <20140606023716.GX17594@otherpad.lan.raisama.net> In-Reply-To: <20140606023716.GX17594@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/2] GET_EMULATED_CPUID support with "allow-emulation" option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Borislav Petkov Cc: Michael Mueller , kvm@vger.kernel.org, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Christian Borntraeger , "Gabriel L. Somlo" , "Jason J. Herne" , Paolo Bonzini , =?ISO-8859-1?Q?Andreas_F=E4rber?= On 06.06.14 04:37, Eduardo Habkost wrote: > On Fri, Jun 06, 2014 at 03:21:04AM +0200, Borislav Petkov wrote: >> On Fri, Jun 06, 2014 at 12:24:26AM +0200, Alexander Graf wrote: >>> But can we drop the EMULATED name somehow? Can we rename [1] the ioctl >>> to say GET_UNSUPPORTED_CPUID or something along those lines? The name >>> is just a really really bad pick. >> What do you mean, a "bad pick" :-P? I added extra care in naming that >> functionality what it is - bitfield in CPUID format of *emulated* >> features. Unsupported is wrong too - we do support them if we enable >> them explicitly. :-) >> >> How about GET_NOT_REALLY_FAST_BUT_STILL_NOT_FAST_ENOUGH_AS_IN_HW_FAST_CPUID? > IMO, "emulated" on the kernel interface is good, because it describe > what it is. Deciding which emulated features are "experimental" or "good > enough to be enabled implicitly even if emulated" is policy for > userspace to decide. > > "allow-experimental" is being mapped to GET_EMULATED_CPUID initially > only because _by default_ the GET_EMULATED_CPUID-only features won't be > enabled implicitly unless forced. But if one day we decide that > emulation is good enough for a specific feature, we can make > kvm_arch_get_supported_cpuid() return it even if it is present only on > the GET_EMULATED_CPUID bitmap. Even if that decision depends on a > specific implementation of that feature, the kernel can report that > using KVM capabilities (to be checked by kvm_arch_get_supported_cpuid(), > like we already do for tsc-deadline). Ok, works for me. I still don't see the point in having the bitmap at all then when we need to carry separate CAPs for individual features' "working" status, but if it makes people happy I'm ok with it. Alex