From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: BUG with Win7 and user-return-notifier Date: Wed, 28 Oct 2009 18:00:32 +0200 Message-ID: <4AE86AA0.1060802@redhat.com> References: <4AE6ED18.9040901@siemens.com> <4AE6F17C.1070403@redhat.com> <4AE6F1EE.5090207@siemens.com> <4AE6F4A3.3050903@redhat.com> <4AE6F4C4.3000802@redhat.com> <4AE7FE3B.2070802@redhat.com> <4AE84EB4.1010603@siemens.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010300040209010505070106" Cc: kvm To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52194 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754846AbZJ1QAe (ORCPT ); Wed, 28 Oct 2009 12:00:34 -0400 In-Reply-To: <4AE84EB4.1010603@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: This is a multi-part message in MIME format. --------------010300040209010505070106 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/28/2009 04:01 PM, Jan Kiszka wrote: > Avi Kivity wrote: > >> On 10/27/2009 03:25 PM, Avi Kivity wrote: >> >>> On 10/27/2009 03:24 PM, Avi Kivity wrote: >>> >>>> Worked for me - getting to the initial prompt. Do you have >>>> >>>> CONFIG_USER_RETURN_NOTIFIER=y >>>> >>>> in your .config? >>>> >>>> >>> If you do, send your own .config, will try to reproduce. >>> >>> >> As I can't reproduce it, can you send a trace of what's going on? >> >> The kvm:kvm_msr and kvm:kvm_cr events should suffice to understand >> what's going on. Please enlarge your buffer size (buffer_size_kb) so we >> don't drop events. >> >> > Find such a trace attached. I hope I caught all important events (there > were tons of identical kvm_cr events before them which I cut off). > [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? -- error compiling committee.c: too many arguments to function --------------010300040209010505070106 Content-Type: text/x-patch; name="efer-debug.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="efer-debug.patch" diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 85f97d1..6bd6d2c 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -590,6 +590,8 @@ static bool update_transition_efer(struct vcpu_vmx *vmx) u64 guest_efer; u64 ignore_bits; + printk("%s: efer_offset %d efer %llx\n", + __func__, efer_offset, vmx->vcpu.arch.shadow_efer); if (efer_offset < 0) return false; guest_efer = vmx->vcpu.arch.shadow_efer; @@ -606,10 +608,11 @@ static bool update_transition_efer(struct vcpu_vmx *vmx) ignore_bits &= ~(u64)EFER_SCE; #endif if ((guest_efer & ~ignore_bits) == (host_efer & ~ignore_bits)) - return false; + return printk("%s: ignoring all bits\n", __func__), false; guest_efer &= ~ignore_bits; guest_efer |= host_efer & ignore_bits; + printk("%s: transition efer %llx\n", __func__, guest_efer); vmx->guest_msrs[efer_offset].data = guest_efer; return true; } @@ -928,8 +931,11 @@ 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)) { + printk("%s: marking efer for reload\n", __func__); move_msr_up(vmx, index, save_nmsrs++); + } else + printk("%s: marking efer for no reload\n", __func__); vmx->save_nmsrs = save_nmsrs; --------------010300040209010505070106--