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

[Blue Swirl]

On Wed, Jul 4, 2012 at 8:05 AM, Avi Kivity <address@hidden> wrote:
> On 07/03/2012 10:06 PM, Blue Swirl wrote:
>> 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.
>
> 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
>
>