Jan Kiszka wrote: > Avi Kivity wrote: >> On 10/28/2009 10:40 PM, Jan Kiszka wrote: >>>> [you can get longer, more detailed traces by using >>>> /sys/kernel/debug/tracing/trace instead of dmesg] >>>> >>>> Oct 28 14:29:56 mchn012c kernel: qemu-sys-7200 0...1. 676996395us : >>>> kvm_msr: msr_read c0000080 = 0x500 >>>> Oct 28 14:29:56 mchn012c kernel: qemu-sys-7200 0...1. 676996403us : >>>> kvm_msr: msr_write c0000080 = 0xd01 >>>> >>>> So Windows is setting EFER.SCE and EFER.NX while in long mode - >>>> perfectly reasonable. Can you rerun with the attached debug patch? >>>> >>>> >>> Log attached. >>> >> So the last bits are: >> >> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: efer_offset 4 >> efer d01 >> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: ignoring all bits >> Oct 28 21:26:41 mchn012c kernel: setup_msrs: marking efer for no reload >> >> We're not reloading efer (correctly, as guest efer == host efer), yet >> vmx_save_host_state() fails while loading efer. I've looked at >> move_msr_up() (which is used by setup_msrs() to partition the msr space >> into reloaded and non-reloaded msrs), and it seems correct. >> >> Can you see any way where update_transition_efer() returns false, yet >> efer turns up in the first save_nmsrs entries of vmx->guest_msrs? >> > > Question: When a VCPU migrates, what syncs the shared_msrs per-cpu vars > before or after that, or why is this no problem? > > I'm currently following the theory that guest_msrs contains some > non-EFER entry with 0 value, but shared_msrs has a different index in > the slot passed to kvm_set_shared_msr. > OK, EFER is a globally shared msr. But there still needs to be a consensus on the slot id used for guest_msrs and shared_msrs_global.msrs, right? move_msr_up works per-vcpu and is obviously decoupled... Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- 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
