x86/boot: Document the ordering dependency of _svm_cpu_up()

Lets just say this took an unreasonable amount of time and effort to track
down, when trying to move traps_init() earlier during boot.

When the SYSCALL linkage MSRs are not configured ahead of _svm_cpu_up() on the
BSP, context switch clobbers the later-set-up linkage with the 0's cached
here.  Amongst other problems, this causes PV guest to enter at 0 in
supervisor mode on the user stack.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit c2f15b0fff)

xen/arch/x86/hvm/svm/svm.c

@@ -1579,6 +1579,20 @@ static int _svm_cpu_up(bool bsp)
     /* Initialize OSVW bits to be used by guests */
     svm_host_osvw_init();
 
+    /*
+     * VMSAVE writes out the current full FS, GS, LDTR and TR segments, and
+     * the GS_SHADOW, SYSENTER and SYSCALL linkage MSRs.
+     *
+     * The segment data gets modified by the svm_load_segs() optimisation for
+     * PV context switches, but all values get reloaded at that point, as well
+     * as during context switch from SVM.
+     *
+     * If PV guests are available, it is critical that the SYSCALL linkage
+     * MSRs been configured at this juncture even in FRED mode.
+     */
+    if ( IS_ENABLED(CONFIG_PV) )
+        ASSERT(rdmsr(MSR_STAR) == XEN_MSR_STAR);
+
     svm_vmsave_pa(per_cpu(host_vmcb, cpu));
 
     return 0;

xen/arch/x86/setup.c

@@ -2078,7 +2078,7 @@ void asmlinkage __init noreturn __start_xen(void)
                                            &this_cpu(stubs).mfn);
     BUG_ON(!this_cpu(stubs.addr));
 
-    traps_init(); /* Needs stubs allocated. */
+    traps_init(); /* Needs stubs allocated, must be before presmp_initcalls. */
 
     cpu_init();