[Xen-ia64-devel] RE: Rebased xen-ia64 tree with VT-i support

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> Maybe I lose sync with bk tree? I "bk pull" and still see 
> ia64_handle_irq is the entry point for interrupt handler, 
> which is in irq_ia64.c. What's new in xenirq.c is some xen 
> specific guest irq handle (xen_do_irq) called by 
> ia64_handle_irq. So for CONFIG_VTI, our interrupt handler is 
> vmx_ia64_handle_irq, which is in same level as 
> ia64_handle_irq, not as xen_do_irq. Hope it clear now. :)

No, you are correct.  I was thinking about xen_do_IRQ in xenirq.c.
Sorry I neglected to check the code before I answered.

I would still move vmx_ia64_handle_irq to a separate file
as there's enough (though minor) differences from ia64_handle_irq.
Either xenirq.c or, if you prefer, a new vmx_irq.c?

> 80% agree based on current model, if you're sure this patched 
> approach will last for a long time. :)

I intend to keep the patches at least until Linux/ia64 evolution
slows down.  There are still a number of Linux/ia64 changes in
most of the files Xen/ia64 leverages in each release of Linux/ia64
and I want to ensure we are able to use those.

> But as a note, the patch to system.h and processor.h will 
> still exist which may simply remove original definition and 
> include "xen_***" specific header to contain new definition. 
> The reason is the difficulty to handle multiple redefinitions 
> without any change to original file. But that patch will be 
> stable, and later changes only happen in "xen_***" as you expected.

Yes, I guess I recall that now from when I transparently paravirtualized
linux for vBlades.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel