From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWnVR-0002Ir-CT for qemu-devel@nongnu.org; Wed, 15 Jun 2011 06:39:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWnVP-0008VL-PP for qemu-devel@nongnu.org; Wed, 15 Jun 2011 06:39:29 -0400 Received: from goliath.siemens.de ([192.35.17.28]:24987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWnVP-0008Uw-2D for qemu-devel@nongnu.org; Wed, 15 Jun 2011 06:39:27 -0400 Message-ID: <4DF88BD9.2050106@siemens.com> Date: Wed, 15 Jun 2011 12:39:21 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DF33413.9070605@web.de> <4DF5CE2E.50008@redhat.com> <4DF6FB62.60705@web.de> <4DF87717.9090007@redhat.com> <4DF88773.3050401@web.de> In-Reply-To: <4DF88773.3050401@web.de> Content-Type: text/plain; charset=ISO-8859-15 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: Avi Kivity Cc: Christophe Fergeau , Marcelo Tosatti , qemu-devel , kvm , Stefan Hajnoczi On 2011-06-15 12:20, Jan Kiszka wrote: > On 2011-06-15 11:10, Avi Kivity wrote: >> 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. >> > > OK. So if bit 2 of IA32_MISC_ENABLE MSR, we must save that fields. But > if it's off, how to test for that other condition "last non-transparent > FP instruction ... had an unmasked exception" from the host? I briefly thought about status.ES == 1. But the guest may clear the flag in its exception handler before reading opcode etc. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux