From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: 2 CPU Conformance Issue in KVM/x86 Date: Tue, 3 Mar 2015 15:31:30 +0100 Message-ID: <20150303143129.GA10875@potion.brq.redhat.com> References: <54F58471.7020906@redhat.com> <6EC0D209-63B4-4D08-976E-3BA15E736B0E@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Paolo Bonzini , kvm list To: Nadav Amit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51884 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756543AbbCCObf (ORCPT ); Tue, 3 Mar 2015 09:31:35 -0500 Content-Disposition: inline In-Reply-To: <6EC0D209-63B4-4D08-976E-3BA15E736B0E@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: 2015-03-03 12:18+0200, Nadav Amit: > Paolo Bonzini 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 =E2=80=9Cgreat=E2=80=9D= =2E Ideas and feedback > >> would be appreciated. > >>=20 > >> 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 !=3D 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 zer= o. 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]. > >=20 > > I think this was analyzed a couple years ago and we decided that th= is bit > > was not virtualizable. >=20 > I am fully aware of the previous reports ( https://lkml.org/lkml/2013= /10/16/258 ). >=20 > 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.