[lkml]   [2010]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/5] KVM&genirq: Enable adaptive IRQ sharing for passed-through devices
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.


[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2010-12-04 15:57    [W:0.040 / U:4.656 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site