Re: [PATCH 0/5] KVM&genirq: Enable adaptive IRQ sharing for passed-throughdevices

[Jan Kiszka]

Am 04.12.2010 15:41, Thomas Gleixner wrote:
> Jan,
> 
> On Sat, 4 Dec 2010, Jan Kiszka wrote:
> 
>> Am 04.12.2010 11:37, Thomas Gleixner wrote:
>>> On Sat, 4 Dec 2010, Jan Kiszka wrote:
>>> If interrupt is shared, then you want to keep the current behaviour:
>>>
>>>    disable at line level (IRQF_ONESHOT)
>>>    run handler thread (PCI level masking)
>>>    reenable at line level in irq_finalize_oneshot()
>>>    reenable at PCI level when guest is done
>>
>> If the interrupt is shared, we must mask at PCI level inside the primary
>> handler as we also have to support non-threaded users of the same line.
>> So we always have a transition line-level -> device-level
>> masking in a primary handler.
> 
> Sorry that left out the hard irq part. Of course it needs to do the
> PCI level masking in the primary one.
>  
>> reduce the latency. So both threaded and non-threaded cases should be
>> addressable by any approach.
> 
> The oneshot magic should work on non threaded cases as well. Needs
> some modifications, but nothing complex.
>  
>>> If interrupts are in flight accross request/free then this change
>>> takes effect when the next interrupt comes in.
>>
>> For registration, that might be too late. We need to synchronize on
>> in-flight interrupts for that line and then ensure that it gets enabled
>> independently of the registered user. That user may have applied
>> outdated information, thus would block the line for too long if user
>> space decides to do something else.
> 
> No, that's really just a corner case when going from one to two
> handlers and I don't think it matters much. If you setup a new driver
> it's not really important whether that first thing comes in a few ms
> later.

The worst case remains infinite (user space never signals end of interrupt).

> 
> Also there is a pretty simple solution for this: The core code knows,
> that there is an ONESHOT interrupt in flight, so it simply can call

It doesn't synchronize the tail part against the masking in the
handler(s), that's driver business.

> the primary handler of that device with the appropriate flag set
> (maybe an additional one to indicate the transition) and let that deal
> with it. Needs some thought vs. locking and races, but that shouldn't
> be hard.

Yes, I thought about this kind of transition (re-invoking the existing
handler) already. We do need notification of the switch (at least for
exclusive->shared) as only the driver can migrate the masking for
in-flight interrupts.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature