From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsuCu-0005Ff-Cw for qemu-devel@nongnu.org; Fri, 06 Jun 2014 09:29:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsuCm-0003LO-U9 for qemu-devel@nongnu.org; Fri, 06 Jun 2014 09:29:20 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:45559) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsuCm-0003K6-PH for qemu-devel@nongnu.org; Fri, 06 Jun 2014 09:29:12 -0400 Received: by mail-wi0-f182.google.com with SMTP id r20so992485wiv.3 for ; Fri, 06 Jun 2014 06:29:11 -0700 (PDT) Sender: Gleb Natapov Date: Fri, 6 Jun 2014 16:29:08 +0300 From: gleb@kernel.org Message-ID: <20140606132907.GR4715@minantech.com> References: <1401984741-26882-1-git-send-email-ehabkost@redhat.com> <539099B6.2090000@suse.de> <53909A41.1060800@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53909A41.1060800@redhat.com> 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: Paolo Bonzini Cc: Eduardo Habkost , kvm@vger.kernel.org, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Alexander Graf , Christian Borntraeger , "Gabriel L. Somlo" , Borislav Petkov , "Jason J. Herne" , Andreas =?utf-8?Q?F=C3=A4rber?= , Michael Mueller On Thu, Jun 05, 2014 at 06:26:41PM +0200, Paolo Bonzini wrote: > Il 05/06/2014 18:24, Alexander Graf ha scritto: > > > >On 05.06.14 18:12, Eduardo Habkost wrote: > >>This implements GET_SUPPORTED_CPUID support using an explicit option > >>for it: > >>"allow-emulation". We don't want any emulated feature to be enabled by > >>accident, > >>so they will be enabled only if the user explicitly wants to allow them. > > > >So is this an all-or-nothing approach? I would really prefer to override > >individual bits. > > You can still disable them with "cpu foo,-movbe,allow-emulation". > > >Also, I don't think the line "emulated" is the right one to draw. We > >"emulate" SVM or VMX too, but still enable them by default as soon as we > >think they're ready enough. > > Well, I disagreed with the whole KVM_GET_EMULATED_CPUID concept for MOVBE > too for example. It seemed overengineered to me, sooner or later we might > graduate MOVBE out of KVM_GET_EMULATED_CPUID as well. Can you remind me what was your argument against KVM_GET_EMULATED_CPUID? Where do you want to move MOVBE to? Supported cpuid? That will make some CPU models unreasonably slow on hosts that do not support MOVBE natively. KVM is not in a busyness of instruction emulation, yes sometimes there is no choice (IO/real mode), sometimes emulating a feature is beneficial (x2apic) and sometimes guest cannot workaround missing feature, so by emulating it you allow guest functionality that is impossible otherwise (SVM/VMX). MOVBE (and MONITOR/MWAIT) is not in any of those categories. By forcing emulation upon unsuspecting guest you force it to use much slower alternative for what it can do by other means. > > However, for MONITOR/MWAIT it makes some sense. > > Paolo > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb.