From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 1/4] KVM: Using kfifo for irq recording Date: Thu, 25 Dec 2008 19:27:38 +0800 Message-ID: <200812251927.39118.sheng@linux.intel.com> References: <1230019973-16833-1-git-send-email-sheng@linux.intel.com> <1230019973-16833-2-git-send-email-sheng@linux.intel.com> <4953696A.5070307@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mga05.intel.com ([192.55.52.89]:23370 "EHLO fmsmga101.fm.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751836AbYLYL1o (ORCPT ); Thu, 25 Dec 2008 06:27:44 -0500 In-Reply-To: <4953696A.5070307@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Thursday 25 December 2008 19:07:22 Avi Kivity wrote: > Sheng Yang wrote: > > For MSI-X, we have to deal with multiply IRQ with same IRQ handler, so > > it's necessary to record the IRQ that trigger the IRQ handler. > > Does MSI-X disallowing coalescing two requests into one interrupt? Or > can we still coalesce interrupts (perhaps by recording them as a (irq, > cpu) pair?) Disallow? Not quite understand. PCI spec said OS don't need to ensure the sequence they handled is the same as they happened. This struct is used just because we lost information of irq after schedule_work... > > @@ -313,6 +314,9 @@ struct kvm_assigned_dev_kernel { > > int host_irq; > > bool host_irq_disabled; > > int guest_irq; > > +#define KVM_ASSIGNED_DEV_IRQ_FIFO_LEN 0x100 > > + struct kfifo *irq_fifo; > > + spinlock_t irq_fifo_lock; > > #define KVM_ASSIGNED_DEV_GUEST_INTX (1 << 0) > > What if it runs out? > > What does real hardware do? I'm sure it doesn't have a 100-entry queue. 0x100 is just a simple number which I thought different interrupts of same MSI-X device can happen at same period(indeed it's 0x100/sizeof(int)). Maybe not that many. And it just used by work function later to find what guest vector is, and then inject the correlated interrupt to the guest. If hardware device driver also postpone the work, I think it also need something like this. -- regards Yang, Sheng