From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH RFC untested] kvm_set_irq: report coalesced for clear Date: Thu, 19 Jul 2012 19:51:23 +0300 Message-ID: <20120719165123.GA17213@redhat.com> References: <20120719091719.GD20120@redhat.com> <20120719092107.GS26120@redhat.com> <20120719093329.GA10182@redhat.com> <20120719094124.GA3459@redhat.com> <20120719102648.GA14101@redhat.com> <20120719105453.GW26120@redhat.com> <20120719111213.GA4364@redhat.com> <20120719112529.GZ26120@redhat.com> <20120719115753.GA9239@redhat.com> <1342715883.3142.17.camel@ul30vt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Gleb Natapov , Avi Kivity , Marcelo Tosatti , kvm@vger.kernel.org To: Alex Williamson Return-path: Received: from mx1.redhat.com ([209.132.183.28]:49277 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750707Ab2GSQut (ORCPT ); Thu, 19 Jul 2012 12:50:49 -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 q6JGomWq026671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Jul 2012 12:50:48 -0400 Content-Disposition: inline In-Reply-To: <1342715883.3142.17.camel@ul30vt> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jul 19, 2012 at 10:38:03AM -0600, Alex Williamson wrote: > Yes, the problem isn't the state. The original patch works just fine to > mask and assert the interrupt every time the device signals and > de-assert and unmask on every EOI. KVM doesn't need to track this for > migration (not that we support migration, of course), we can always just > send an unmask to the device to retrigger an interrupt if needed. I agree, just let's document this in case emulated devices use EOIFD. > The thing Michael is trying to avoid is spurious assertions and > de-assertions by tracking the state machine. Spurious assertions are > not really a problem, at least for vfio where the interrupt is masked > until kvm/qemu tells us to unmask it. So at any point in time we can > reset the state machine with an unmask. Spurious unmasks are > theoretically a problem if an IRQ is shared among multiple devices we > can trigger unmasks for devices that haven't been asserted. vfio > handles this pretty well though and recognizes the device isn't masked > and does nothing. > > Something I note out of this discussion is that while the spinlock I use > to maintain the state machine is ugly, the lock has no contention. Good point. Overall I'm convinced now it was a good idea. > I don't think that's necessarily the case with pic_lock. Anyway, I think > we can do w/o the spinlock altogether. Lock contention and spurious > eois over level triggered interrupts is probably not worth worrying > about. Thanks, good summary. I think I can prove to you spurious wakeups are a problem though: consider a setup where an IRQ is shared with a userspace device (e.g. console). If said userspace uses EOIFD you wake up userspace on each interrupt of an assigned device which is exactly what level IRQFD was designed to avoid. -- MST