Skip to contentSkip to conversation

FPU LWP 3/5: define new FPU interface functions: fpu_save, fpu_restore, fpu_reload

RFC PATCH In review Wei Huang 2 participants 3 messages Apr 14, 2011 – Apr 15, 2011

lore
Share & tools
lore

Wei Huang

author
#0 lore raw

RFC PATCH 1/1 FPU LWP 3/5: define new FPU interface functions: fpu_save, fpu_restore, fpu_reload

Current Xen implementation only support lazy FPU reload via CR0.TS. But new FPU state isn't always tracked by CR0.TS bit. One example is AMD's lightweight profiling. With this patch, Xen calls fpu_save() on vcpu which is being scheduled out and fpu_restore() on vcpu which is being scheduled in. The nonlazy FPU state is saved and restored in these two functions.

This patch also defines fpu_reload() to handle lazy FPU state when #NM is triggered.

# HG changeset patch
# User Wei Huang <[email protected]>
# Date 1302812136 18000
# Branch lwp3
# Node ID bccbc5ecf62e49482c06149bb94dfc3dee8882f1
# Parent f5c4d99cde695bd0342a96d3ea6d5b34bd6047af
FPU: define new FPU interface functions: fpu_save, fpu_restore, fpu_reload

Current Xen implementation only support lazy FPU reload via CR0.TS. But new FPU state isn't always tracked by CR0.TS bit. One example is AMD's lightweight profiling. With this patch, Xen calls fpu_save() on vcpu which is being scheduled out and fpu_restore() on vcpu which is being scheduled in. The nonlazy FPU state is saved and restored in these two functions.

This patch also defines fpu_reload() to handle lazy FPU state when #NM is triggered.

xen/arch/x86/domain.c +1 -0
diff -r f5c4d99cde69 -r bccbc5ecf62e xen/arch/x86/domain.c
@@ -1594,6 +1594,7 @@
         memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
         if ( xsave_enabled(n) && n->arch.xcr0 != get_xcr0() )
             set_xcr0(n->arch.xcr0);
+        fpu_restore(n);
         n->arch.ctxt_switch_to(n);
     }
 
xen/arch/x86/hvm/svm/svm.c +1 -1
diff -r f5c4d99cde69 -r bccbc5ecf62e xen/arch/x86/hvm/svm/svm.c
@@ -348,7 +348,7 @@
 {
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
 
-    fpu_restore(v);
+    fpu_reload(v);
     vmcb_set_exception_intercepts(
         vmcb, vmcb_get_exception_intercepts(vmcb) & ~(1U << TRAP_no_device));
 }
xen/arch/x86/hvm/vmx/vmx.c +1 -1
diff -r f5c4d99cde69 -r bccbc5ecf62e xen/arch/x86/hvm/vmx/vmx.c
@@ -612,7 +612,7 @@
 
 static void vmx_fpu_enter(struct vcpu *v)
 {
-    fpu_restore(v);
+    fpu_reload(v);
     v->arch.hvm_vmx.exception_bitmap &= ~(1u << TRAP_no_device);
     vmx_update_exception_bitmap(v);
     v->arch.hvm_vmx.host_cr0 &= ~X86_CR0_TS;
xen/arch/x86/i387.c +87 -47

179 lines not on this page · raw message

xen/arch/x86/traps.c +1 -1
diff -r f5c4d99cde69 -r bccbc5ecf62e xen/arch/x86/traps.c
@@ -3167,7 +3167,7 @@
 
     BUG_ON(!guest_mode(regs));
 
-    fpu_restore(curr);
+    fpu_reload(curr);
 
     if ( curr->arch.pv_vcpu.ctrlreg[0] & X86_CR0_TS )
     {
xen/include/asm-x86/i387.h +4 -1
diff -r f5c4d99cde69 -r bccbc5ecf62e xen/include/asm-x86/i387.h
@@ -32,6 +32,9 @@
 #define XSTATE_LWP          (1ULL << 62) /* AMD lightweight profiling */
 #define XSTATE_FP_SSE       (XSTATE_FP | XSTATE_SSE)
 #define XCNTXT_MASK         (XSTATE_FP | XSTATE_SSE | XSTATE_YMM | XSTATE_LWP)
+
+#define XSTATE_LAZY         (XSTATE_FP | XSTATE_SSE | XSTATE_YMM)
+#define XSTATE_NONLAZY      (XSTATE_LWP)
 
 #define XSAVEOPT            (1 << 0)
 
@@ -88,5 +91,5 @@
 /******************************/
 extern void fpu_save(struct vcpu *v);
 extern void fpu_restore(struct vcpu *v);
-
+extern void fpu_reload(struct vcpu *v);
 #endif /* __ASM_I386_I387_H */

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#1 lore raw
Quoted 7 lines
Quoted 1 line
Quoted 1 line · Wei Huang

Current Xen implementation only support lazy FPU reload via CR0.TS. But new FPU state isn't always tracked by CR0.TS bit. One example is AMD's lightweight profiling. With this patch, Xen calls fpu_save() on vcpu which is being scheduled out and fpu_restore() on vcpu which is being scheduled in. The nonlazy FPU state is saved and restored in these two functions.

This doesn't match the actual patch - only fpu_restore() is being added to the context switch path, fpu_save() was there already, saving both lazy and non-lazy state.

xen/arch/x86/i387.c line 354

Quoted 7 lines

This patch also defines fpu_reload() to handle lazy FPU state when #NM is triggered.

...

xen/arch/x86/i387.c +2 -0
+/* Restore VCPU's FPU state when the vcpu is scheduled out */
+void fpu_restore(struct vcpu *v)

The comment ought so say "in" rather than "out".

Jan

author
#2 lore raw

Will fix.

-Wei

Quoted 23 lines · Jan Beulich
Quoted 7 lines
Quoted 1 line
Quoted 1 line · Wei Huang

Current Xen implementation only support lazy FPU reload via CR0.TS. But new FPU state isn't always tracked by CR0.TS bit. One example is AMD's lightweight profiling. With this patch, Xen calls fpu_save() on vcpu which is being scheduled out and fpu_restore() on vcpu which is being scheduled in. The nonlazy FPU state is saved and restored in these two functions.

This doesn't match the actual patch - only fpu_restore() is being added to the context switch path, fpu_save() was there already, saving both lazy and non-lazy state.

xen/arch/x86/i387.c line 354

Quoted 7 lines

This patch also defines fpu_reload() to handle lazy FPU state when #NM is triggered.

...

xen/arch/x86/i387.c +2 -0
+/* Restore VCPU's FPU state when the vcpu is scheduled out */
+void fpu_restore(struct vcpu *v)

The comment ought so say "in" rather than "out".

Jan