Re: huh startup_ipi_hook?

[Jeremy Fitzhardinge <jeremy@goop.org>]

Eric W. Biederman wrote:
> 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.
>   

Yes, but I see those as implementation details. In Xen I don't think we
need IPIs for any of those. If a particular implementation needs IPIs
then its free to use them.

> 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.
>   

That's an interesting point. I haven't really looked at giving domains
direct hardware access. Its not something which makes much sense without
a good IOMMU anyway.

> 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.
>   

Well, if i386 and x86_64 make it look like fun, I'm sure ia64 will work
out how to come to the party.


>> 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
>>     
s/Xen/VMI/


J