lkml.org 
[lkml]   [2008]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: kernel BUG at arch/x86/kernel/io_apic_64.c:357!
    Eric W. Biederman wrote:
    >> I'm still interested in making Xen's event channel-based interrupts fit better
    >> into the rest of the interrupt handling scheme. In particular, event channels
    >> map very closely to the x86-64 notion of a vector. There's 1024 of them per
    >> domain, and each is bound to a cpu. At the moment, I map them to irqs, which
    >> means that I need to allocate around 5-6 irqs per cpu, which makes everything
    >> very cluttered. I'd like to map event channels to vectors, and then map vectors
    >> to (irq,cpu) tuples.
    >>
    >
    > Uh.... I'm not certain this applies.
    >

    No, but, hey, it's a hook.

    >> From what I've seen this is exactly how x86-64 currently has things set up, and
    >> I'm interested in making sure that 32-bit does the same thing.
    >>
    >
    > Yes. x86_32 needs work to get cleaned up.
    >
    > The architecture on x86_64 is as follows.
    >
    > We have interrupt sources: GSIs in the case of acpi.
    > We have linux interupts: something with an irq number.
    >
    > Vectors are an internal implementation detail.
    >
    > I don't know if your event channels more closely resemble interrupt sources or internal
    > implementation details. If they are an implementation detail that interrupt sources
    > just flow through we should hide them like we do vectors. If event channels actually are
    > the sources of interrupts we should do something different.
    >

    They're an interrupt source, I guess. They need to be behind some layer
    of indirection because they can be reassigned at arbitrary times (like
    suspend/resume, or if the backend driver just decided to disconnect
    itself), and so they need to get rebound to at least the same irq.

    >> I'm also interested in having vectors being sourced from multiple interrupt
    >> controllers. So, some vectors would be sourced from APICs, and other are
    >> sourced from event channels. This would be useful for Xen domains which have
    >> direct access to hardware (ie, the dom0 control domain in the short term, and
    >> disaggregated driver domains later on), and fully emulated domains which have
    >> paravirtual drivers.
    >>
    >
    > Generally easy except for the disparate methods of catching interrupts.
    >

    Catching in what sense? I assume the interrupt gets raised in some
    source-specific way, and then passed into a generic layer where it
    eventually gets matched with an appropriate handler. I'm sure there's
    some subtlety I'm missing.

    >> I haven't studied the current code to see if this notion already exists or not.
    >>
    >> While the APIC interrupt model is the most architecturally important for the x86
    >> platform, I'd like to make sure we don't build in the assumption that it's the
    >> *only* interrupt model.
    >>
    >
    > Well with iommus starting to show up in our irq paths it looks we are going to get
    > a lot of diversity.
    >
    > Eric
    >
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    >



    \
     
     \ /
      Last update: 2008-07-30 02:53    [W:6.967 / U:0.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site