From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH v2 06/20] kvm: Install optimized interrupt handler Date: Fri, 18 Mar 2011 08:29:11 -0300 Message-ID: <20110318112911.GA2436@amt.cnet> References: <20110315171011.GA25624@amt.cnet> <4D7FC84B.70906@web.de> <4D833180.5020603@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44864 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752861Ab1CRLjV (ORCPT ); Fri, 18 Mar 2011 07:39:21 -0400 Content-Disposition: inline In-Reply-To: <4D833180.5020603@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Mar 18, 2011 at 11:18:40AM +0100, Jan Kiszka wrote: > On 2011-03-15 21:12, Jan Kiszka wrote: > > On 2011-03-15 18:10, Marcelo Tosatti wrote: > >> On Tue, Mar 15, 2011 at 12:26:17PM +0100, Jan Kiszka wrote: > >>> KVM only requires to set the raised IRQ in CPUState and to kick the > >>> receiving vcpu if it is remote. > >>> > >>> Signed-off-by: Jan Kiszka > >>> --- > >>> kvm-all.c | 11 +++++++++++ > >>> 1 files changed, 11 insertions(+), 0 deletions(-) > >>> > >>> diff --git a/kvm-all.c b/kvm-all.c > >>> index 226843c..25ab545 100644 > >>> --- a/kvm-all.c > >>> +++ b/kvm-all.c > >>> @@ -650,6 +650,15 @@ static CPUPhysMemoryClient kvm_cpu_phys_memory_client = { > >>> .log_stop = kvm_log_stop, > >>> }; > >>> > >>> +static void kvm_handle_interrupt(CPUState *env, int mask) > >>> +{ > >>> + env->interrupt_request |= mask; > >>> + > >>> + if (!qemu_cpu_is_self(env)) { > >>> + qemu_cpu_kick(env); > >>> + } > >>> +} > >>> + > >> > >> Not sure its worthwhile to allow different handlers. The advantage over > >> tcg version is that its shorter, without cpu_unlink_tb and icount > >> handler? > > > > I thought about this again as well before posting, and I came to the > > conclusion that an important advantage is avoiding TCG surprises in KVM > > code paths. This way, KVM does not need to bother if cpu_unlink_tb or > > icount related code changes. Maybe I should have added this to the > > commit message. > > What's your opinion on this? Should I repost the remaining three with > comments adjusted? > > Jan > Its up to you. Your argument above makes sense.