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(-)
>>>
>
next prev parent 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