[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.024 / U:45.784 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site