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

[Jan Kiszka]

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<address@hidden>
>>>>>
>>>>>  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