From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: external module sched_in event Date: Sat, 22 Dec 2007 21:13:44 +0200 Message-ID: <476D61E8.5000102@qumranet.com> References: <20071220162353.GA3802@v2.random> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Andrea Arcangeli Return-path: In-Reply-To: <20071220162353.GA3802-lysg2Xt5kKMAvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Andrea Arcangeli wrote: [snip] > So in short with the below fix applied, after a write_tsc(0,0), the > UP guest never return any error anymore. Previously it would return > frequent errors because sched_in wasn't properly invoked by svm.c and > it would crash at boot every single time after a write_tsc(0,0). > > The SMP guest of course still returns TSC errors but that's ok, the > smp host also return TSC errors, that's ok, it's only the UP guest > that is forbidden to have a not monotone TSC or the guest would crash > like it happened to me. > > I'm unsure if special_reload_db7 is needed at all, but it certainly > can't hurt so it's the only hack I left. > It's needed, vmx (and IIRC svm) will clear out db7 so we must reload it. In fairness we need also reload it if the host had it set; it shouldn't be a hack but part of mainline. > Finally I can enjoy KVM stability too ;). If you always compiled your > host kernel with CONFIG_KVM=y on a recent kernels including the > preempt-notifiers, you could never run into this. If you compile your > host kernel with CONFIG_KVM=n please try to test this. > Unfortunately, this fails badly on Intel i386: > kvm: emulating preempt notifiers; do not benchmark on this machine > loaded kvm module (kvm-56-127-g433be51) > vmwrite error: reg c08 value d8 (err 3080) > [] vmx_save_host_state+0x4f/0x162 [kvm_intel] > [] __cond_resched+0x25/0x3c > [] kvm_arch_vcpu_ioctl_run+0x16f/0x3a7 [kvm] > [] kvm_vcpu_ioctl+0xcb/0x28f [kvm] > [] enqueue_entity+0x2c0/0x2ea > [] skb_dequeue+0x39/0x3f > [] unix_stream_recvmsg+0x3a2/0x4c3 > [] scheduler_tick+0x1a1/0x274 > [] core_sys_select+0x21f/0x2fa > [] clockevents_program_event+0xb5/0xbc > [] avc_has_perm+0x4e/0x58 > [] inode_has_perm+0x66/0x6e > [] recalc_sigpending+0xb/0x1d > [] dequeue_signal+0xa9/0x12a > [] getnstimeofday+0x30/0xbf > [] file_has_perm+0x89/0x91 > [] kvm_vcpu_ioctl+0x0/0x28f [kvm] > [] do_ioctl+0x21/0xa0 > [] vfs_ioctl+0x237/0x249 > [] sys_ioctl+0x4c/0x67 > [] sysenter_past_esp+0x5f/0x85 > ======================= vmwrite error means the vmcs pointer was not loaded, probably because the sched_in event did not fire after a vcpu migration. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/