[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 11.10.13 at 03:01, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
> 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.
> Is it better to move the change to VMX specific code or keep them as it is 
> now?

Keep them as they're now as long as the SVM folks don't have
an issue with them (which apparently they don't as long as you
don't try to do the field replacement I had thought might be


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.