Hi, I've been experimenting with Linux 4.14 on Xen 4.6. Now that Intel microcode is generally available, I'm starting to exercise the new mitigation code paths.
For Xen 4.6-4.8, microcode loading happens after init_speculation_mitigations, so Xen only detects the boot firmware features. The early microcode loading f97838bbd980 ("x86: Move microcode loading earlier") can be cherry-picked, though small fix ups are needed for bool/true/false -> bool_t/1/0 and smpboot.c:smp_store_cpu_info() to retain "struct cpuinfo_x86 *c = cpu_data + id;". With that in place, I'm seeing Dom0 receive a general protection fault on boot [ 25.460035] general protection fault: 0000 [#1] SMP [ 25.460292] EIP: switch_mm_irqs_off+0xbe/0x600 switch_mm_irqs_off+0xbe is the inlined indirect_branch_prediction_barrier(void) { alternative_msr_write(MSR_IA32_PRED_CMD, PRED_CMD_IBPB, X86_FEATURE_USE_IBPB); } The system boots when dom0 disables IBPB manipulation with nospectre_v2 on the kernel command line. I think Xen ends up here in xen/arch/x86/traps.c:emulate_privileged_op(), case MSR_PRED_CMD: domain_cpuid(currd, 7, 0, &dummy, &dummy, &dummy, &edx); domain_cpuid(currd, 0x80000008, 0, &dummy, &ebx, &dummy, &dummy); if ( !(edx & cpufeat_mask(X86_FEATURE_IBRSB)) && !(ebx & cpufeat_mask(X86_FEATURE_IBPB)) ) goto fail; /* MSR available? */ /* * The only defined behaviour is when writing PRED_CMD_IBPB. In * practice, real hardware accepts any value without faulting. */ if ( eax & PRED_CMD_IBPB ) wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB); break; ...but Dom0 doesn't have a cpuid policy configured, so the IBRSB/IBPB check fails and we GP. Did I read that correctly? If that is the case, how should Dom0 be handled? Other 4.14 PV & HVM DomUs boot fine and detect (and use?) IBPB once Dom0 boots (with spectre mitigations disabled). Regards, Jason _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel