Re: [PATCH v2] x86/nSVM: Save L2's CR0, CR4 and EFER on #VMEXIT, not Xen's

[Jan Beulich <jbeulich@xxxxxxxx>]

On 30.09.2026 03:26, Lin Liu wrote:
>>> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
>>> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
>>> @@ -1079,11 +1079,11 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct 
>>> cpu_user_regs *regs)
>>>      ns_vmcb->_cpl = n2vmcb->_cpl;
>>>  
>>>      /* EFER */
>>> -    ns_vmcb->_efer = n2vmcb->_efer;
>>> +    ns_vmcb->_efer = v->arch.hvm.guest_efer;
>>>  
>>>      /* CRn */
>>> -    ns_vmcb->_cr4 = n2vmcb->_cr4;
>>> -    ns_vmcb->_cr0 = n2vmcb->_cr0;
>>> +    ns_vmcb->_cr4 = v->arch.hvm.guest_cr[4];
>>> +    ns_vmcb->_cr0 = v->arch.hvm.guest_cr[0];
>>>  
>>>      /* DRn */
>>>      ns_vmcb->_dr7 = n2vmcb->_dr7;
>>
>> ... I still think it is a mistake to leave alone the similar CR2 handling
>> code further down in the function. Yes, #PF handling in
>> nsvm_vcpu_vmexit_inject() updates the value, but as indicated before that
>> (aiui) still leaves (at least) the case where L2 writes CR2 explicitly.
>> ...
>> Jan
> 
> Sorry I was about to reply in the thread of v1 ...
> 
> Yes, L2 guest can write CR2 explicitly, and the value goes to the shadow, e.g:
> n2vmcb, which is the good reason the value need to be copied back from n2vmcb,
> rather than the guest_cr backup.

Yet using v->arch.hvm.guest_cr[2] would be equally correct, wouldn't it?
svm_vmexit_handler() syncs the value first thing.

Jan