All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Andre Przywara" <andre@andrep.de>,
	kvm@vger.kernel.org, "Jörg Rödel" <joro@8bytes.org>,
	"H. Peter Anvin" <hpa@zytor.com>, x86-ml <x86@kernel.org>
Subject: Re: [PATCH -v2] kvm: Emulate MOVBE
Date: Tue, 16 Apr 2013 20:42:36 +0300	[thread overview]
Message-ID: <20130416174236.GE5807@redhat.com> (raw)
In-Reply-To: <20130414173215.GD20547@pd.tnic>

On Sun, Apr 14, 2013 at 07:32:16PM +0200, Borislav Petkov wrote:
> On Sun, Apr 14, 2013 at 10:41:07AM +0300, Gleb Natapov wrote:
> > Currently userspace assumes that that cpuid configuration returned by
> > KVM_GET_SUPPORTED_CPUID is the optimal one. What we want here is a way
> > for KVM to tell userspace that it can emulate movbe though it is not
> > optimal.
> 
> Ok, I don't understand.
> 
> You want to tell userspace: "yes, we do support a hw feature but we
> emulate it."?
> 
I am contemplating this, yes.

> > Userspace alone cannot figure it out. It can check host's cpuid
> > directly and assume that if cpuid bit is not present on the host cpu,
> > but reported as supported by KVM then it is emulated by KVM and this is
> > not optimal, but sometimes emulation is actually desirable (x2apic), so
> > such assumption is not always correct.
> 
> Right, and this is what we have, AFAICT. And if userspace does that what
> you exemplify above, you get exactly that - a feature bit not set in
> CPUID but KVM reporting it set means, it is emulated. There's no room
> for other interpretations here. Which probably means also not optimal
> because it is not done in hw.
> 
This is not true for all emulated CPUID bits. X2APIC is emulated and it
is preferable for a guest to use it for example.

> Or, do you want to have a way to say with KVM_GET_SUPPORTED_CPUID that
> "the features I'm reporting to you are those - a subset of them are not
> optimally supported because I'm emulating them."
> 
> Am I close?
> 
Yes, you are. I am considering such interface. Adding new specialized interfaces
is last resort though. I am open to other ideas.

--
			Gleb.

  parent reply	other threads:[~2013-04-16 17:43 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-09 23:46 [RFC PATCH] Emulate MOVBE Borislav Petkov
2013-04-10  0:03 ` Borislav Petkov
2013-04-10  0:04   ` H. Peter Anvin
2013-04-10  9:53     ` Borislav Petkov
2013-04-10  9:29 ` Andre Przywara
2013-04-10 10:08   ` Gleb Natapov
2013-04-10 10:17     ` Borislav Petkov
2013-04-10 10:21       ` Gleb Natapov
2013-04-10 10:39     ` Andre Przywara
2013-04-10 12:16       ` Gleb Natapov
2013-04-11  0:18         ` [PATCH -v2] kvm: " Borislav Petkov
2013-04-11 14:28           ` Gleb Natapov
2013-04-11 15:37             ` Borislav Petkov
2013-04-14  7:41               ` Gleb Natapov
2013-04-14 17:32                 ` Borislav Petkov
2013-04-14 18:36                   ` H. Peter Anvin
2013-04-14 19:09                     ` Borislav Petkov
2013-04-14 19:40                       ` H. Peter Anvin
2013-04-16 17:42                   ` Gleb Natapov [this message]
2013-04-17 11:04                     ` Borislav Petkov
2013-04-17 13:38                       ` Gleb Natapov
2013-04-17 14:02                         ` Borislav Petkov
2013-04-18 22:48                           ` Borislav Petkov
2013-04-21  9:46                             ` Gleb Natapov
2013-04-21 11:30                               ` Borislav Petkov
2013-04-21 12:51                                 ` Gleb Natapov
2013-04-23 23:41                                   ` Borislav Petkov
2013-04-23 23:50                                     ` H. Peter Anvin
2013-04-24  8:42                                       ` Gleb Natapov
2013-04-24  8:47                                       ` Borislav Petkov
2013-04-14  8:43           ` Gleb Natapov
2013-04-14 21:02             ` Borislav Petkov
2013-04-16 11:36               ` Paolo Bonzini
2013-04-21 11:46                 ` Borislav Petkov
2013-04-21 12:23                   ` Borislav Petkov
2013-04-22  8:53                     ` Paolo Bonzini
2013-04-22  9:38                       ` Borislav Petkov
2013-04-22  9:42                         ` Gleb Natapov
2013-04-22  9:52                           ` Borislav Petkov
2013-04-22  9:58                             ` Gleb Natapov
2013-04-22 13:49                               ` Borislav Petkov
2013-04-26 16:08                         ` Borislav Petkov
2013-04-16 11:47     ` [RFC PATCH] " Paolo Bonzini
2013-04-16 12:08       ` Borislav Petkov
2013-04-16 12:13         ` H. Peter Anvin
2013-04-16 17:28       ` Gleb Natapov
2013-04-17 10:42         ` Paolo Bonzini
2013-04-17 13:33           ` Gleb Natapov

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=20130416174236.GE5807@redhat.com \
    --to=gleb@redhat.com \
    --cc=andre@andrep.de \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.