On Mon, Jul 2, 2012 at 9:43 AM, Avi Kivity <avi@xxxxxxxxxx> 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. 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? > > For device assignment or vhost, we can have a qemu_irq_irqfd() which > converts a qemu_irq to an eventfd. If the route calculations determine > that it can be serviced via a real irqfd, they also configure it as an > irqfd. Otherwise qemu configures a poll on this eventfd and calls the > callback when needed. > > > -- > error compiling committee.c: too many arguments to function > > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
