[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Teddy Astie <teddy.astie@xxxxxxxxxx>
  • Date: Mon, 4 May 2026 14:31:06 +0200
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Mon, 04 May 2026 12:31:22 +0000
  • Feedback-id: default:8631fc262581453bbf619ec5b2062170:Sweego
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Le 01/05/2026 à 23:43, Andrew Cooper a écrit :
> 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

Reviewed-by: Teddy Astie <teddy.astie@xxxxxxxxxx>


--
 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.