On Wed, Jul 4, 2012 at 8:05 AM, Avi Kivity <avi@xxxxxxxxxx> wrote: > 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. I wasn't thinking of using fds, I guess that could work too but just that the interface could be similar to packet filters. So a device which implements an enable switch and ORs 8 inputs to a global output could be implemented with: context = rule_init(); context = append_rule(context, R_OR, 8, &irq_array[]); context = append_rule(context, R_AND, 1, irq_enable); send_to_kernel_or_master_irq_controller(context); > > 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. If this is efficient, some of the internal logic inside devices (for example PCI) could be implemented with the rules. Usually devices have one or just a few IRQ outputs but several possible internal sources for these. > > -- > 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
