[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |