RE: [Xen-devel] In VMCS, HOST_CR0.TS is always set 1. Why?

["Cui, Dexuan" <dexuan.cui@xxxxxxxxx>]

I see.
Thanks for the clear explanation!

-- Dexuan


Keir Fraser wrote:
> On 14/11/07 10:29, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> wrote:
> 
>>>      /* Host control registers. */
>>> -    __vmwrite(HOST_CR0, read_cr0());
>>> +    __vmwrite(HOST_CR0, read_cr0() | X86_CR0_TS);
>>>      __vmwrite(HOST_CR4, read_cr4());
>>> 
>>>      /* Host CS:RIP. */
>> 
>> Hi Steven,
>> The description of the changeset says "This fixes a number of subtle
>> FP corruption issues within PV domains when running alongside VMX
>> ones" -- can you tell me what the subtle issues are?
> 
> At the time we construct the vmcs, the dom0 process may already have
> dirtied the fpu in this timeslice and hence CR0.TS is clear. If that
> is the case then every time this VMCS is vmexited we will load CR0
> with TS cleared. Not really a problem while that VMX guest is
> running, but if we context-switch to a PV guest, and the VMX guest
> has not dirtied the FPU, then our context-switch logic will assume
> that CR0.TS must be set and so not explicitly set it. So then the PV
> guest runs and will be able to access the FPU without having its
> state restored (because CR0.TS already == 0). 
> 
>  -- Keir

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel