On 07/03/2012 10:06 PM, Blue Swirl wrote: > 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. 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 -- 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
