We weren't passing the right xcr0. Who knows what we were passing. This caused the FP state to be partially restored.
Whenever we migrated a thread/VM between pcores, we wouldn't get all of the new FP state, such as having bad xmms. We often would see parts of the correct FP state from previous residents of the core, and the xmms were probably clobbered by another thread calling into glibc for e.g. memset(). Signed-off-by: Barret Rhoden <[email protected]> --- https://www.youtube.com/watch?v=HeKx6EuMZWM user/parlib/include/parlib/x86/arch.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/parlib/include/parlib/x86/arch.h b/user/parlib/include/parlib/x86/arch.h index 58b2e4ec77f4..3866189fe7b2 100644 --- a/user/parlib/include/parlib/x86/arch.h +++ b/user/parlib/include/parlib/x86/arch.h @@ -155,7 +155,7 @@ static inline void restore_fp_state(struct ancillary_state *silly) if (cpu_has_feat(CPU_FEAT_X86_XSAVE)) { edx = x86_default_xcr0 >> 32; eax = x86_default_xcr0; - asm volatile("xrstor64 %0" : : "m"(*silly)); + asm volatile("xrstor64 %0" : : "m"(*silly), "a"(eax), "d"(edx)); } else { asm volatile("fxrstor64 %0" : : "m"(*silly)); } -- 2.8.0.rc3.226.g39d4020 -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
