Re: [Qemu-devel] plan for device assignment upstream

[Blue Swirl]

On Mon, Jul 2, 2012 at 9:43 AM, Avi Kivity <address@hidden> 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
>
>
>