Re: [Xen-devel] Restoring FPU exception state

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.02.16 at 11:33, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Tian, Kevin
>> Sent: Thursday, February 18, 2016 2:31 PM
>> 
>> >
>> > > If the VCPU is descheduled between these two checks, the contents of
>> > > FCS/FDS is lost, Windows will notice and BugCheck.
>> > >
>> > > When saving a VCPUs FPU state, Xen first uses a REX.W prefixed XSAVE and
>> > > notices that FIP/FDP[64:32] is non-zero and assumes are REX.W prefixed
>> > > XRSTOR is required to restore the full 64-bits of FIP/FDP.  This clears
>> > > FCS/FDS.
>> > >
>> > > On processors with FPCSDS[2] (bit 13) set in CPUID leaf 0x7, sub-leaf
>> > > 0x0, do not save FCS/FDS (they always write zeros) and this problem does
>> > > not occur, because FCS/FDS never needs to be restored.
>> > >
>> > > Does anyone any thoughts of a solution for processors without the FPCSDS
>> > > feature?
>> >
>> > One would assume they have a solution to this problem on Hyper-V,
>> > but then again their solution may simply be that they don't use REX
>> > prefixes anywhere (i.e. namely also not in context switch code). In
>> > which case, though, they'd corrupt state of their non-Windows guests.
>> >
>> > But to answer your question: I have no idea. The handling of these
>> > FPU code/data pointers has been an unloved child from the very
>> > beginning of the x86-64 architecture. All I could see us doing would
>> > be to add a per-domain control to override the auto-detection in the
>> > XSAVE code path.
>> >
>> 
>> Interesting. Let me also have a check internally whether there is other
>> architectural alternative.
> 
> Looks there is no other good alternative. FPCSDS is right introduced
> to address this issue, but then it means only for newer platform.

Except that it breaks migration from older hosts (storing these fields)
to newer hosts (storing zero instead). I really think this feature
should have been an opt-in one (i.e. to be enabled via some control
register bit), instead of one thats always on.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel