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. However, there are some side effects that need a closer look, likely also in other places where vmx_set_cr0 is used directly. E.g. load_pdptrs. The lack of calling them on host->guest switch may explain the PAE issues you once saw with your nEPT implementation. OK, more work... Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
