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

[Lin Liu <lin.liu01@xxxxxxxxxx>]

>> --- 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.

Lin