Re: BUG with Win7 and user-return-notifier

Jan Kiszka
2009-10-29T16:07:55Z

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.

Jan

--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux