From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: KVM: x86: use smp_send_reschedule in kvm_vcpu_kick Date: Mon, 9 Mar 2009 11:58:55 +0100 Message-ID: <20090309105855.GA14242@elte.hu> References: <20090303001405.GA5889@amt.cnet> <49B4ECB6.8060505@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Marcelo Tosatti , kvm@vger.kernel.org, Gleb Natapov , Peter Zijlstra To: Avi Kivity Return-path: Received: from mx2.mail.elte.hu ([157.181.151.9]:37757 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753532AbZCIK7G (ORCPT ); Mon, 9 Mar 2009 06:59:06 -0400 Content-Disposition: inline In-Reply-To: <49B4ECB6.8060505@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: * Avi Kivity wrote: > Marcelo Tosatti wrote: >> KVM uses a function call IPI to cause the exit of a guest running on a >> physical cpu. For virtual interrupt notification there is no need to >> wait on IPI receival, or to execute any function. >> >> This is exactly what the reschedule IPI does, without the overhead >> of function IPI. So use it instead of smp_call_function_single in >> kvm_vcpu_kick. >> >> Also change the "guest_mode" variable to a bit in vcpu->requests, and >> use that to collapse multiple IPI's that would be issued between the >> first one and zeroing of guest mode. >> >> This allows kvm_vcpu_kick to called from interrupt context. >> > > Looks good. The only worry I have is that we depend on > smp_reschedule_interrupt() being a no-op. I guess that's a > reasonable assumption though. It's a reasonable current assumption - but it might change in the future - so please also put it into the changelog that KVM will revert it or fix it differently if the scheduler grows some functionality there. Ingo