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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/05/2026 6:14 am, Jan Beulich wrote:
> On 02.05.2026 00:21, Andrew Cooper wrote:
>> On 01/05/2026 10:44 pm, Stefano Stabellini wrote:
>>> On Fri, 1 May 2026, Andrew Cooper wrote:
>>>> 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>
>>> Tested-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>> Thanks, sadly I made the mistake of extending my XTF PoC for this.
>>
>> There are also bugs on the emulated MOV-to-CR2 side, and they're far
>> harder to untangle.
> Any slightly closer details as to what?

hvmemul_write_cr() updates guest_cr[2] but doesn't sync it into the
VMCB.  This doesn't show up on Intel because CR2 is switched explicitly
in RAX across VMEntry/exit.

But, it's not the only problem path.

svm_vmexit_do_cr_access() is the fasthpath exit for CR intercepts when
decode assists are available.  hvm_mov_to_cr() and hvm_mov_from_cr() are
asymmetric in their handling of CR2.  mov_from will read from
guest_cr[2] but mov_to will domain crash.

However, case 2 ought to be unreachable in hvm_mov_from_cr() because of
how we program the intercepts, yet the QEMU bug which caused this to get
noticed will trigger an ASSERT() if I were to put one in.

So, do I fix up both to account for the fact we know QEMU is buggy with
intercepts?

>
>> This patch probably wants to go in in this form, accepting that there
>> are issues still to be addressed on the other side.
> I agree:
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks.

~Andrew