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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
