[PATCH] x86/svm: Always sync guest CR2 on VMExit

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

Under SVM, there are two copies of guest CR2.  One is v->arch.hvm.guest_cr[2]
and one is in the VMCB.

Xen doesn't intercept CR2 accesses, so this mostly goes unnoticed; hardware
loads and saves the guest CR2 across VMRUN/VMExit.

For HAP guests (where #PF is not intercepted, and therefore we don't typically
inject #PF either), this causes the guest CR2 value to be lost on migrate.  As
migration is cooperative and not done from the #PF handler, this also goes
unoticed by guests.

It also means that an emulated MOV-from-CR2 reads a stale value.

Reported-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Fixes: d1bd157fbc9b ("Big merge the HVM full-virtualisation abstractions.")
Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
---
CC: Jan Beulich <jbeulich@xxxxxxxx>
CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
CC: Teddy Astie <teddy.astie@xxxxxxxxxx>
CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>

It also also works around the QEMU bug that triggered the investigion, where
the CR2 intercepts trigger despite Xen requesting CR2 not to be intercepted.
---
 xen/arch/x86/hvm/svm/svm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index ced616684732..f49d2ebbfdd5 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2505,6 +2505,7 @@ void asmlinkage svm_vmexit_handler(void)
     hvm_sanitize_regs_fields(
         regs, !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l));
 
+    v->arch.hvm.guest_cr[2] = vmcb_get_cr2(vmcb);
     if ( paging_mode_hap(v->domain) )
         v->arch.hvm.guest_cr[3] = v->arch.hvm.hw_cr[3] = vmcb_get_cr3(vmcb);
 

base-commit: 61f957d48c78df6c5254b6f54d6170d3bd3d717e
-- 
2.39.5