[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.