Re: [Xen-devel] [PATCH] Nested VMX: CR emulation fix up

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Boris Ostrovsky wrote on 2013-10-10:
> On 10/09/2013 08:31 PM, Zhang, Yang Z wrote:
>> Boris Ostrovsky wrote on 2013-10-09:
>>> On 10/09/2013 03:28 AM, Zhang, Yang Z wrote:
>>>> Boris Ostrovsky wrote on 2013-10-08:
>>>>> On 10/08/2013 04:31 AM, Jan Beulich wrote:
>>>>> 
>>>>>> Considering that this touches code common with nested SVM, I'd
>>>>>> expect the SVM maintainers to have to approve of the change in any
>>>>>> case.
>>>>>> 
>>>>>> In particular I wonder whether this addition isn't obsoleting
>>>>>> SVM's ns_cr0.
>>>>>> 
>>>>> I am not sure whether ns_cr0 (replaced with nv_guest_cr[0]) would
>>>>> then be updated in paths where it currently is not.
>>>>> 
>>>>> For example in nsvm_vmcb_prepare4vmrun():
>>>>> 
>>>>>        /* CR0 */ svm->ns_cr0 = v->arch.hvm_vcpu.guest_cr[0]; cr0 =
>>>>>        nestedsvm_fpu_vmentry(svm->ns_cr0, ns_vmcb, n1vmcb, n2vmcb);
>>>>>        v->arch.hvm_vcpu.guest_cr[0] = ns_vmcb->_cr0; rc =
>>>>>        hvm_set_cr0(cr0);  <------ nv_guest_cr[0] will get set here.
>>>> I am not familiar with SVM code. If you think this change may
>>>> impact the
>>> nested SVM. Then I will move the change to VMX specific code.
>>> 
>>> No, it doesn't affect SVM code. I was responding to Jan's
>>> suggestion to replace SVM's ns_cr0 with the new guest_cr[0].
>> So is it ok to change the code according Jan's suggestion?
> 
> No. My point was that there may be unintended consequences to the
> change and you should leave ns_cr0 alone.

Hi Jan,

Is it better to move the change to VMX specific code or keep them as it is now?

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel