On Sat, Feb 23, 2013 at 11:57 PM, Jan Kiszka <jan.kis...@web.de> wrote:
> On 2013-02-23 22:45, Nadav Har'El wrote:
>> On Sat, Feb 23, 2013, Jan Kiszka wrote about "[PATCH] KVM: nVMX: Replace 
>> kvm_set_cr0 with vmx_set_cr0 in load_vmcs12_host_state":
>>> -    kvm_set_cr0(vcpu, vmcs12->host_cr0);
>>> +    vmx_set_cr0(vcpu, vmcs12->host_cr0);
>>
>> I don't remember now why I did this (and I'm not looking at the code),
>> but this you'll need to really test carefully, including
>> shadow-on-shadow mode (ept=0 in L0), to verify you're not missing any
>> important side-effect of kvm_set_cr0.
>>
>> Also, if I remember correctly, during nVMX's review, Avi Kivity asked
>> in several places that when I called vmx_set_cr0, I should instead call
>> kvm_set_cr0(), because it does some extra stuff and does some extra
>> checks. Hmm, see, see this:
>>       http://markmail.org/message/hhidqyhbo2mrgxxc
>>
>> where Avi asked for the reverse patch you're attempting now.
>
> At least, kvm_set_cr0 can't be used as it assumes an otherwise
> consistent guest state and an explicitly initiated transition - which is
> naturally not the case while emulating a vmexit.

We have the same problem in KVM_SET_SREGS.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to