Re: [Qemu-devel] [PATCH][uq/master] kvm: x86: Save/restore FPU OP, IP and DP

[Avi Kivity <avi@redhat.com>]

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<jan.kiszka@siemens.com>
> >>
> >>  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