All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, kvm list <kvm@vger.kernel.org>
Subject: Re: 2 CPU Conformance Issue in KVM/x86
Date: Tue, 3 Mar 2015 15:31:30 +0100	[thread overview]
Message-ID: <20150303143129.GA10875@potion.brq.redhat.com> (raw)
In-Reply-To: <6EC0D209-63B4-4D08-976E-3BA15E736B0E@gmail.com>

2015-03-03 12:18+0200, Nadav Amit:
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 03/03/2015 09:34, Nadav Amit wrote:
> >> I got two conformance issues in x86/KVM. For the first one I have no
> >> solution. For the latter, my solution is not “great”. Ideas and feedback
> >> would be appreciated.
> >> 
> >> The first problem is caused by the deprecating of FPU CS/DS in new Intel
> >> CPUs. Assume the VM executes a floating point instruction in real mode (when
> >> CS != 0), and later KVM exits to userspace, causing XSAVE/XRSTOR to save and
> >> restore the FPU state. At this point FPU CS/DS in new CPUs are zero. If the
> >> VM then executes FSAVE in real-mode the save FPU IP would be wrong, since it
> >> is actually calculated by the CPU as [FPU CS] * 4 + [FPU IP].
> > 
> > I think this was analyzed a couple years ago and we decided that this bit
> > was not virtualizable.
> 
> I am fully aware of the previous reports ( https://lkml.org/lkml/2013/10/16/258 ).
> 
> However, one might have expected the conformance problem to be fully
> resolved now, since [FPU CS] and [FPU DS] are deprecated in new CPUs.
> Indeed, the problem is resolved in all modes, but not in real-mode.

Since we can't get the CS/DS from real FPUs, we'd have to do ugly and
slow hacks to virtualize it (checking all possible changes of FPU
pointers and code segments).

I think that forcing the deprecation bit to guest CPUID, if set on host,
would be the best compromise between correctness and sanity.

  reply	other threads:[~2015-03-03 14:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-03  8:34 2 CPU Conformance Issue in KVM/x86 Nadav Amit
2015-03-03  9:52 ` Paolo Bonzini
2015-03-03 10:18   ` Nadav Amit
2015-03-03 14:31     ` Radim Krčmář [this message]
2015-03-09 17:08   ` Avi Kivity
2015-03-09 17:51     ` Nadav Amit
2015-03-09 18:23       ` Avi Kivity
2015-03-09 19:07         ` Nadav Amit
2015-03-09 19:19           ` Avi Kivity
2015-03-09 19:38             ` Paolo Bonzini
2015-03-09 19:49               ` Avi Kivity
2015-03-10 10:47                 ` Paolo Bonzini
2015-03-10 20:38                   ` Avi Kivity
2015-03-09 19:33     ` Paolo Bonzini
2015-03-09 19:50       ` Avi Kivity
2015-03-10 10:44         ` 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=20150303143129.GA10875@potion.brq.redhat.com \
    --to=rkrcmar@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=nadav.amit@gmail.com \
    --cc=pbonzini@redhat.com \
    /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.