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?
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4264e09..0b1f461 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -928,8 +928,10 @@ static void setup_msrs(struct vcpu_vmx *vmx)
}
#endif
vmx->msr_offset_efer = index = __find_msr_index(vmx, MSR_EFER);
- if (index >= 0 && update_transition_efer(vmx))
+ if (index >= 0 && update_transition_efer(vmx)) {
+ vmx->msr_offset_efer = save_nmsrs;
move_msr_up(vmx, index, save_nmsrs++);
+ }
vmx->save_nmsrs = save_nmsrs;
?
Untested as I don't want to crash my notebook ATM. :)
Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
