> changeset 15216: 6f13c3be08fahttp://xenbits.xensource.com/xen-unstable.hg?rev/6f13c3be08fa> --- a/xen/arch/x86/hvm/vmx/vmcs.c Mon Jun 04 15:41:32 2007 +0100 > +++ b/xen/arch/x86/hvm/vmx/vmcs.c Mon Jun 04 16:47:48 2007 +0100 > @@ -337,7 +337,7 @@ static void construct_vmcs(struct vcpu * > #endif> /* 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? Thanks! -- Dexuan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Nov-14 11:15 UTC
Re: [Xen-devel] In VMCS, HOST_CR0.TS is always set 1. Why?
On 14/11/07 10:29, "Cui, Dexuan" <dexuan.cui@intel.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Cui, Dexuan
2007-Nov-14 11:44 UTC
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@intel.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel