public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>,
	Igor Mammedov <imammedo@redhat.com>,
	linux-kernel@vger.kernel.org
Cc: gleb@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	x86@kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 0/2] KVM: x86 emulator: emulate MOVAPS and MOVAPD SSE instructions
Date: Mon, 17 Mar 2014 18:01:07 +0100	[thread overview]
Message-ID: <53272A53.8090605@redhat.com> (raw)
In-Reply-To: <fb38ff9d-8c00-4b02-b0da-2db989f7190e@email.android.com>

Il 17/03/2014 16:16, H. Peter Anvin ha scritto:
> After seeing the sheer number of one-off additions, I'm wondering if going through the opcode map systematically and see what is still missing might not be a bad idea.

Memory access instructions always need emulation, but there aren't that 
many left.  There are some, such as MOVUPS/MOVUPD.

However, this is not the only use of emulation.  The problem stems from 
pre-Westmere Intel chips that didn't have unrestricted mode 
virtualization.  For these chips, you need to emulate all instructions 
that might be used in protected mode transitions and also, possibly, in 
big real mode.  In practice you will rarely see big real mode (the main 
exception is option ROMs, due to PMM), still every OS likes to do 
something different in their protected mode transitions so this is the 
source of most one-off additions that you have seen.

Until around 3.6, KVM used to transform big real mode into a "good" real 
mode that the processor would like, while breaking completely in big 
real mode; this is now emulate_invalid_guest_state=N.  Nowadays, it uses 
emulation, which is emulate_invalid_guest_state=Y.  As you can imagine 
it's quite slow (though some performance can certainly be scraped off 
the emulator).

If CS and possibly SS are valid real mode selectors, it should be 
possible to run big real mode at almost-full speed, taking exits only 
for memory accesses via other segment registers.  It is on my todo list, 
but not very high.  Depending on the exit overhead, it may be a better 
idea to revert the emulate_invalid_guest_state default to N and let 
people who care about big real mode specify Y.

Paolo

> On March 17, 2014 2:30:43 AM PDT, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 15/03/2014 23:42, H. Peter Anvin ha scritto:
>>> Stupid question... what instructions do NOT need emulsion in KVM? It
>> would seem that at least anything that touches memory would?
>>
>> Yes, indeed.  Anything that touches memory can be used on MMIO and then
>>
>> needs emulation.
>>
>> Paolo
>>
>>> On March 15, 2014 1:01:58 PM PDT, Igor Mammedov <imammedo@redhat.com>
>> wrote:
>>>> MS HCK test fails on 32-bit Windows 8.1 due to missing MOVAPS
>>>> instruction emulation, this series adds it and while at it,
>>>> it adds emulation of MOVAPD which is trivial to implement on
>>>> top of MOVAPS.
>>>>
>>>> Igor Mammedov (2):
>>>>  KVM: x86 emulator: emulate MOVAPS
>>>>  KVM: x86 emulator: emulate MOVAPD
>>>>
>>>> arch/x86/kvm/emulate.c | 8 +++++++-
>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>

  reply	other threads:[~2014-03-17 17:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-15 20:01 [PATCH 0/2] KVM: x86 emulator: emulate MOVAPS and MOVAPD SSE instructions Igor Mammedov
2014-03-15 20:01 ` [PATCH 1/2] KVM: x86 emulator: emulate MOVAPS Igor Mammedov
2014-03-15 20:02 ` [PATCH 2/2] KVM: x86 emulator: emulate MOVAPD Igor Mammedov
2014-03-15 22:39 ` [PATCH 0/2] KVM: x86 emulator: emulate MOVAPS and MOVAPD SSE instructions H. Peter Anvin
2014-03-17 11:19   ` Paolo Bonzini
2014-03-15 22:42 ` H. Peter Anvin
2014-03-17  9:30   ` Paolo Bonzini
2014-03-17 15:16     ` H. Peter Anvin
2014-03-17 17:01       ` Paolo Bonzini [this message]
2014-03-17 17:38         ` H. Peter Anvin
2014-03-18 12:11           ` Paolo Bonzini
2014-03-17 11:18 ` Paolo Bonzini

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=53272A53.8090605@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=gleb@kernel.org \
    --cc=hpa@zytor.com \
    --cc=imammedo@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox