On Sun, Feb 24, 2013 at 11:01 AM, Jan Kiszka <jan.kiszka@xxxxxx> wrote: > On 2013-02-24 09:56, Avi Kivity wrote: >> On Sat, Feb 23, 2013 at 11:57 PM, Jan Kiszka <jan.kiszka@xxxxxx> 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. > > I don't see the problem. kvm_arch_vcpu_ioctl_set_sregs open-codes the > state update, not applying any transition checks. That's the problem. We have this open coding in three different places (KVM_SET_SREGS, nvmx, nsvm). It's not as if vmx_set_cr0() is defined as "kvm_set_cr0() without the transition checks". -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
