Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
From: Alexander van Heukelum
Date: Tue Nov 04 2008 - 12:39:44 EST
On Tue, 4 Nov 2008 17:54:09 +0100, "Ingo Molnar" <mingo@xxxxxxx> said:
>
> * Alexander van Heukelum <heukelum@xxxxxxxxxxx> wrote:
>
> > > My estimation is that if we do it right, your approach will behave
> > > better on modern CPUs (which is what matters most for such
> > > things), especially on real workloads where there's a considerable
> > > instruction-cache pressure. But it should be measured in any case.
> >
> > Fully agreed. I will do some measurements in the near future, maybe
> > next week. At least noone came up with an absolutely blocking
> > problem with this approach ;).
>
> how about "it does not build with lguest enabled" as a blocking
> problem? ;-)
>
> arch/x86/lguest/built-in.o: In function `lguest_init_IRQ':
> boot.c:(.init.text+0x33f): undefined reference to `interrupt'
The following makes it compile... Whether it works is a different
question ;).
index a5d8e1a..ad7e292 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -580,6 +580,7 @@ static struct irq_chip lguest_irq_controller = {
* interrupt (except 128, which is used for system calls), and then
tells the
* Linux infrastructure that each interrupt is controlled by our
level-based
* lguest interrupt controller. */
+void maininterrupt(void);
static void __init lguest_init_IRQ(void)
{
unsigned int i;
@@ -590,7 +591,7 @@ static void __init lguest_init_IRQ(void)
* a straightforward 1 to 1 mapping, so force that here.
*/
__get_cpu_var(vector_irq)[vector] = i;
if (vector != SYSCALL_VECTOR) {
- set_intr_gate(vector, interrupt[vector]);
+ set_intr_gate(vector, maininterrupt);
set_irq_chip_and_handler_name(i,
&lguest_irq_controller,
handle_level_irq,
"level");
> config attached.
>
> Ingo
--
Alexander van Heukelum
heukelum@xxxxxxxxxxx
--
http://www.fastmail.fm - One of many happy users:
http://www.fastmail.fm/docs/quotes.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/