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: Fri, 26 Dec 2008 09:53:10 +0800 Message-ID: <200812260953.10740.sheng@linux.intel.com> References: <1230019973-16833-1-git-send-email-sheng@linux.intel.com> <200812251927.39118.sheng@linux.intel.com> <49538A05.1020104@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 mga10.intel.com ([192.55.52.92]:16191 "EHLO fmsmga102.fm.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752233AbYLZBxO (ORCPT ); Thu, 25 Dec 2008 20:53:14 -0500 In-Reply-To: <49538A05.1020104@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Thursday 25 December 2008 21:26:29 Avi Kivity wrote: > Sheng Yang wrote: > > 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... > > Why can't we store this information in a bitmap? There are a limited > number of irqs. > > The only reason I can think of for using a fifo is if we want to > preserve the number and ordering of interrupts. Is there another reason? Well, I just think using fifo is more generic and unify the logic of three type of interrupt easily, something seems more elegant. > >>> @@ -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. > > Maybe it's better to do the conversion immediately, so we can store the > information in a structure that's not prone to overflow. OK. I would give a bitmap to kvm struct with gsi_msg which is unable to overflow. -- regards Yang, Sheng