From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWm7v-0005Px-KL for qemu-devel@nongnu.org; Wed, 15 Jun 2011 05:11:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWm7t-0001tD-EY for qemu-devel@nongnu.org; Wed, 15 Jun 2011 05:11:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWm7t-0001se-7R for qemu-devel@nongnu.org; Wed, 15 Jun 2011 05:11:05 -0400 Message-ID: <4DF87717.9090007@redhat.com> Date: Wed, 15 Jun 2011 12:10:47 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4DF33413.9070605@web.de> <4DF5CE2E.50008@redhat.com> <4DF6FB62.60705@web.de> In-Reply-To: <4DF6FB62.60705@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH][uq/master] kvm: x86: Save/restore FPU OP, IP and DP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Christophe Fergeau , Marcelo Tosatti , qemu-devel , kvm , Stefan Hajnoczi On 06/14/2011 09:10 AM, Jan Kiszka wrote: > On 2011-06-13 10:45, Avi Kivity wrote: > > On 06/11/2011 12:23 PM, Jan Kiszka wrote: > >> From: Jan Kiszka > >> > >> These FPU states are properly maintained by KVM but not yet by TCG. So > >> far we unconditionally set them to 0 in the guest which may cause > >> state corruptions - not only during migration. > >> > >> > >> -#define CPU_SAVE_VERSION 12 > >> +#define CPU_SAVE_VERSION 13 > >> > > > > Incrementing the version number seems excessive - I can't imagine a > > real-life guest will break due to fp pointer corruption > > > > However, I don't think we have a mechanism for optional state. We > > discussed this during the 18th VMState Subsection Symposium and IIRC > > agreed to re-raise the issue when we encountered it, which appears to be > > now. > > > > Whatever we invent, it has to be backported as well to allow that > infamous traveling back in time, migrating VMs from newer to older versions. > > Would that backporting be simpler if we used an unconditional subsection > for the additional states? Thinking about it, a conditional subsection would work fine. Most threads will never see an fpu error, and are all initialized to a clean slate. SDM 1 8.1.9.1 says: > 8.1.9.1 Fopcode Compatibility Sub-mode > Beginning with the Pentium 4 and Intel Xeon processors, the IA-32 > architecture > provides program control over the storing of the last instruction > opcode (sometimes > referred to as the fopcode). Here, bit 2 of the IA32_MISC_ENABLE MSR > enables (set) > or disables (clear) the fopcode compatibility mode. > If FOP code compatibility mode is enabled, the FOP is defined as it > has always been > in previous IA32 implementations (always defined as the FOP of the > last non-trans- > parent FP instruction executed before a FSAVE/FSTENV/FXSAVE). If FOP code > compatibility mode is disabled (default), FOP is only valid if the > last non-transparent > FP instruction executed before a FSAVE/FSTENV/FXSAVE had an unmasked > exception. So fopcode will usually be clear. -- error compiling committee.c: too many arguments to function