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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.05.2026 18:24, Andrew Cooper wrote:
> 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?

I think that's going to be (about) the best we can do.

Jan