[Xen-ia64-devel] consoles, iosapics, and device interrupts

[Alex Williamson <alex.williamson@xxxxxx>]

Hi,

   I was looking at fixing up the console support on xen/ia64 since I
really don't like getting multiple copies of every printk and I can't
switch back and forth between the xen and dom0 console.  (is everyone
seeing this?)  The early console can easily be eliminated by adding a
CON_BOOT flag to it when calling register_console():

--- a/linux-2.6-xen-sparse/arch/ia64/xen/xenconsole.c   Thu Nov 10 21:24:29 2005
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/xenconsole.c   Fri Nov 11 08:56:06 2005
@@ -9,6 +9,7 @@
        extern int running_on_xen;
        if (running_on_xen) {
                extern struct console hpsim_cons;
+               hpsim_cons.flags |= CON_BOOT;
                register_console(&hpsim_cons);
                return 0;
        }

This gets us down to the printk only getting printed twice when using a
serial console.  The console in drivers/xen/console registers itself as
a serial interface for dom0, thus creating ttyS0.  x86 is not including
8250 serial console support in the dom0 kernel because of this.
Eliminating that from the ia64 defconfig gets us down to printks only
being printed once:

--- a/linux-2.6-xen-sparse/arch/xen/configs/xen0_defconfig_ia64 Thu Nov 10 
21:24:29 2005
+++ b/linux-2.6-xen-sparse/arch/xen/configs/xen0_defconfig_ia64 Fri Nov 11 
08:58:24 2005
@@ -549,15 +549,7 @@
 #
 # Serial drivers
 #
-CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_ACPI=y
-CONFIG_SERIAL_8250_NR_UARTS=8
-CONFIG_SERIAL_8250_EXTENDED=y
-CONFIG_SERIAL_8250_SHARE_IRQ=y
-# CONFIG_SERIAL_8250_DETECT_IRQ is not set
-# CONFIG_SERIAL_8250_MULTIPORT is not set
-# CONFIG_SERIAL_8250_RSA is not set
+# CONFIG_SERIAL_8250 is not set
 
 #
 # Non-8250 serial port support

   Here's the problem (or at least the start of it); we don't seem to be
getting any input into the ns16550 driver in the xen hypervisor.  Since
I'm on an HP box that does not use legacy interrupts for serial lines,
the interrupt comes in through an IOSAPIC.  We currently don't seem to
have any support for external interrupts through IOSAPICs.  I thought
about simply adding polling support to ns16550, but w/o any timer
support in the hypervisor, that looks non-trivial.  So, I was thinking
about pulling the IOSAPIC code over.  This means we'll have to iterate
all the IOSAPICs in the MADT to discover where the GSIs are mapped just
so we can poke the right one for the serial port.  We can't hide this
one IOSAPIC RTE from the domains, but unless I missed something, we
already have IOSAPIC sharing issues if we ever have multiple privileged
domains with I/O anyway.  I'm leery to even get into all the issues
surrounding setting up interrupt polarity and trigger based on the PCDP
tables.

   Does this sound like the right way to go?  I feel like I'm opening a
can of worms by adding a dependency to an IOSAPIC RTE that we're
eventually going to hand over to a domain that may clear the interrupt
vector we want to enable.  Thoughts?  Thanks,

        Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab


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