[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?



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


 


Rackspace

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