Re: huh startup_ipi_hook?

[ebiederm@xmission.com (Eric W. Biederman)]

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Eric W. Biederman wrote:
>> That may work but at first glance that feels a little to high level,
>> and a little lacking.
>>
>> What I am certain of is that we need a general ability to send
>> inter processor interrupts.  Beyond that I haven't looked closely
>> yet.
>>   
>
> IPIs are used for three things: function calls, reschedule and tlb
> flush. smp_ops covers function calls and reschedule, and paravirt_ops
> has a cross-cpu tlb flush operation (which is not implemented as an IPI
> under Xen, since it knows what real cpus actually have stale state).

I was thinking of our magic process specific vectors and those
aren't quite IPIs.  But there are some other uses to add to your list
but not necessarily in general we have irq migration, irq
retransmission, sending NMIs to shootdown cpus.

> In the Xen model, hardware interrupts are mapped to event channels, and
> you can arrange for even channel IDs to be mapped directly to hardware
> irqs. But this is why I'm very interested in making the irq space
> dynamically allocatable, so that we can use event channel IDs directly
> as irqs, and easily have disjoint ranges for hardware statically
> allocated events and dynamic events.

What I don't understand is how do we map MSI's to event channels.
That is going to be an interesting one.  Because the drivers in
essence decide how many of those the hardware will have.

>> Partly I suspect you haven't been getting some of the review you could
>> have because arch/i386 is not that interesting right now.  arch/x86_64
>> is where the code is generally clean, and new hardware support work
>> tends to focus.
>>   
>
> That may be. I've been waiting to see what the outcome of the 32/64 bit
> merge discussions before launching into 64-bit paravirt_ops (though
> rostedt and glommer have made a good start on it).

I'm a little interested in that as well.  It would be good to have a
common place for the shared code.  Although I wonder if it is only
arch/i386 and arch/x86_64 that need to be in the discussion.
arch/ia64 has some significant pieces of shared heritage.  Although
nowhere near as much.

> Yes, and its tricky in places to have a single interface which is
> supposed to deal with both Xen and VMI, since they're often at opposite
> ends of the abstraction spectrum. So we end up with a high-level
> interface which calls into Xen code and the existing native code, and
> then some hooks in the native code to call out to Xen. If the native
> code were refactored a little more, I think this would come out fairly
> cleanly (ie, use it as a library of code which talks to hardware and
> things (mostly) emulating hardware). Things get a bit strange with VMI
> where it mixes hardware emulation with paravirtualization - the timer
> stuff, for example.

Yes.

Eric