From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH RFC untested] kvm_set_irq: report coalesced for clear Date: Thu, 19 Jul 2012 12:21:07 +0300 Message-ID: <20120719092107.GS26120@redhat.com> References: <20120718221152.GA14049@redhat.com> <20120719075337.GQ26120@redhat.com> <20120719091719.GD20120@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Marcelo Tosatti , kvm@vger.kernel.org, Alex Williamson To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:48623 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752159Ab2GSJVJ (ORCPT ); Thu, 19 Jul 2012 05:21:09 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6J9L9Bh002683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Jul 2012 05:21:09 -0400 Content-Disposition: inline In-Reply-To: <20120719091719.GD20120@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jul 19, 2012 at 12:17:19PM +0300, Michael S. Tsirkin wrote: > On Thu, Jul 19, 2012 at 10:53:37AM +0300, Gleb Natapov wrote: > > On Thu, Jul 19, 2012 at 01:11:53AM +0300, Michael S. Tsirkin wrote: > > > This creates a way to detect when kvm_set_irq(...,0) was run > > > twice with the same source id by returning 0 in this case. > > > > > > Signed-off-by: Michael S. Tsirkin > > > --- > > > > > > This is on top of my bugfix patch. Uncompiled and untested. Alex, I > > > think something like this patch will make it possible for you to simply > > > do > > > if (kvm_set_irq(...., 0)) > > > eventfd_signal() > > > > > Why caller can't track line state? > > Why duplicate information? As we are finding it's not trivial to keep > the two in sync. Think about migration etc ... > We do not migrate irq_states. The caller already have to have enough information to recreate its state and it should migrate the info, so why should we go all the way down the call chain to find something that is already known? -- Gleb.