Martin J. Bligh wrote: >OK, I need to do something like this to io_apic.c - split the hardware >specific parts out under mach-default, so we can override them for other >subarchitectures. It's not finished, needs header file and makefile >work. Would you be willing to take this if I do it? I'm not going to >bother if you're not, such refactorings are a pig to maintain out of >tree. > >Frankly, io_apic.c needs a damned good scrubbing anyway, but this seems >like a reasonable first step to me. (we also need to cross-link better >with x86_64 code, but ...not all in one go ;-)). > > Is it actually necessary to use the ioapic for paravirtualized Linux? I was thinking you might be able to abstract around the problem by defining a new hw_interrupt_type, and providing custom handler routines in the sub-architecture - Visual Workstation is one sub-arch that does this. See arch/i386/mach-visws/visws_apic.c for an interrupt controller implementation that doesn't require hacking up apic / ioapic. This approach could be used to wrap Xen event channels onto virtual IRQs in Linux. For SMP support you need to send IPIs as well - but this is easy enough, include/asm-i386/mach-xxx/mach_ipi.h is already a standard way to hook IPIs for the sub-arch. Are there other reasons for requiring the APIC code to be dissected? It is really messy in there, and it might be simpler to wrap around the Xen event / irq model directly by using the sub-arch to its fullest. Two possible reasons I can think of might be that privileged domains need to actually control the hardware interrupt system, or that it is just easier to emulate the APIC for all guests since non-paravirtualized guests will need it as well (and thus you have only one interrupt system to debug). These are both highly debatable and highly dubious speculations on my part. That said, I'm not adverse to hacking up the APIC code to encapsulate the hardware accessors, I'm just unsure if it is actually a requirement. Zach
