From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmKaH-0008Ap-7q for qemu-devel@nongnu.org; Wed, 04 Jul 2012 04:05:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmKaE-0006Ad-Jf for qemu-devel@nongnu.org; Wed, 04 Jul 2012 04:05:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29621) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmKaE-0006AI-BQ for qemu-devel@nongnu.org; Wed, 04 Jul 2012 04:05:10 -0400 Message-ID: <4FF3F92C.8010501@redhat.com> Date: Wed, 04 Jul 2012 11:05:00 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20120702091813.GF8268@redhat.com> <4FF16A21.7050309@siemens.com> <4FF16D54.3020801@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] plan for device assignment upstream List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: kvm , "Michael S. Tsirkin" , Jan Kiszka , Marcelo Tosatti , Michael Tokarev , "qemu-devel@nongnu.org" On 07/03/2012 10:06 PM, Blue Swirl wrote: > On Mon, Jul 2, 2012 at 9:43 AM, Avi Kivity wrote: >> On 07/02/2012 12:30 PM, Jan Kiszka wrote: >>> On 2012-07-02 11:18, Michael S. Tsirkin wrote: >>>> I've been thinking hard about Jan's patches for device >>>> assignment. Basically while I thought it makes sense >>>> to make all devices: assignment and not - behave the >>>> same and use same APIs for injecting irqs, Anthony thinks there is huge >>>> value in making irq propagation hierarchical and device assignment >>>> should be special cased. >>> >>> On the long term, we will need direct injection, ie. caching, to allow >>> making it lock-less. Stepping through all intermediate layers will cause >>> troubles, at least performance-wise, when having to take and drop a lock >>> at each stop. >> >> So we precalculate everything beforehand. Instead of each qemu_irq >> triggering a callback, calculating the next hop and firing the next >> qemu_irq, configure each qemu_irq array with a function that describes >> how to take the next hop. Whenever the configuration changes, >> recalculate all routes. > > Yes, we had this discussion last year when I proposed the IRQ matrix: > http://lists.nongnu.org/archive/html/qemu-devel/2011-09/msg00474.html > > One problem with the matrix is that it only works for enable/disable > level, not for more complex situations like boolean logic or > multiplexed outputs. I think we do need to support inverters etc. > Perhaps the devices should describe the currently valid logic with > packet filter type mechanism? I think that could scale arbitrarily and > it could be more friendly even as a kernel interface? Interesting idea. So qemu creates multiple eventfds, gives half to devices and half to kvm (as irqfds), and configures bpf programs that calculate the irqfd outputs from the vfio inputs. At least for x86 this is overkill. I would be okay with one-input-one-output cases handled with the current code and everything else routed through qemu. -- error compiling committee.c: too many arguments to function