qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: gleb@kernel.org
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, "Alexander Graf" <agraf@suse.de>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Gabriel L. Somlo" <gsomlo@gmail.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Jason J. Herne" <jjherne@linux.vnet.ibm.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Michael Mueller" <mimu@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [RFC 0/2] GET_EMULATED_CPUID support with "allow-emulation" option
Date: Fri, 6 Jun 2014 16:29:08 +0300	[thread overview]
Message-ID: <20140606132907.GR4715@minantech.com> (raw)
In-Reply-To: <53909A41.1060800@redhat.com>

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.

  parent reply	other threads:[~2014-06-06 13:29 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-05 16:12 [Qemu-devel] [RFC 0/2] GET_EMULATED_CPUID support with "allow-emulation" option Eduardo Habkost
2014-06-05 16:12 ` [Qemu-devel] [RFC 1/2] kvm: Implement kvm_arch_get_emulated_cpuid() Eduardo Habkost
2014-06-05 16:12 ` [Qemu-devel] [RFC 2/2] target-i386: Add "allow-emulation" X86CPU property Eduardo Habkost
2014-06-05 19:57   ` [Qemu-devel] [RFC 2/2 v2] target-i386: Add "x-allow-emulation" " Eduardo Habkost
2014-06-05 22:27     ` Alexander Graf
2014-06-05 16:24 ` [Qemu-devel] [RFC 0/2] GET_EMULATED_CPUID support with "allow-emulation" option Alexander Graf
2014-06-05 16:26   ` Paolo Bonzini
2014-06-05 16:40     ` Alexander Graf
2014-06-05 16:44       ` Paolo Bonzini
2014-06-05 16:45         ` Alexander Graf
2014-06-05 16:52           ` Paolo Bonzini
2014-06-05 16:54             ` Alexander Graf
2014-06-05 16:57               ` Paolo Bonzini
2014-06-05 17:19                 ` Eduardo Habkost
2014-06-05 17:39                   ` Paolo Bonzini
2014-06-05 18:02                     ` Eduardo Habkost
2014-06-05 19:12                       ` Eduardo Habkost
2014-06-05 19:24                         ` Borislav Petkov
2014-06-05 19:45                           ` Eric Blake
2014-06-05 19:52                             ` Eduardo Habkost
2014-06-05 16:58             ` Alexander Graf
2014-06-05 17:48               ` Eduardo Habkost
2014-06-05 22:24                 ` Alexander Graf
2014-06-06  1:21                   ` Borislav Petkov
2014-06-06  2:37                     ` Eduardo Habkost
2014-06-06 11:16                       ` Alexander Graf
2014-06-06 18:38                         ` Eduardo Habkost
2014-06-05 17:17           ` Eduardo Habkost
2014-06-05 17:38             ` Paolo Bonzini
2014-06-05 17:52               ` Eduardo Habkost
2014-06-05 17:34       ` Eduardo Habkost
2014-06-06 13:29     ` gleb [this message]
2014-06-05 18:11   ` Eduardo Habkost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140606132907.GR4715@minantech.com \
    --to=gleb@kernel.org \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=bp@alien8.de \
    --cc=ehabkost@redhat.com \
    --cc=gsomlo@gmail.com \
    --cc=jjherne@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=mimu@linux.vnet.ibm.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).