On 10/29/2009 10:03 AM, 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?
Without understanding the code completely yet: When you push the slot
containing EFER around, do you also update msr_offset_efer?
We don't, but msr_offset_efer is only used from
update_transition_efer(), which is only ever called from setup_msrs()
immediately after updating msr_offset_efer.
Of course, it should be an argument to update_transition_efer(), I'll
clean up this leftover.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
