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

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

First patch (hpsim_cons) committed.  I'll try to get the
8250 config removal out in the next round of config file
changes.

Any further thinking on the console input issue?

Dan 

> -----Original Message-----
> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf 
> Of Williamson, Alex (Linux Kernel Dev)
> Sent: Friday, November 11, 2005 9:27 AM
> To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-ia64-devel] consoles, iosapics, and device interrupts
> 
> 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
> 

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