WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

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

On Mon, 2005-11-21 at 12:51 +0200, Tristan Gingold wrote:
> Le Vendredi 18 Novembre 2005 16:52, Alex Williamson a écrit :

> >    AFAICT, ns16550 only outputs a character at a time, so interrupt vs
> > polling doesn't really come into play for early output.  The problem
> > though is how do we get the irq data back into ns16550?  We have to call
> > acpi_register_gsi() to translate the PCDP provided GSI to an irq vector.
> > That can only be done after acpi_boot_init() finds the IOSAPICs in
> > late_setup_arch().  We certainly don't want to go blind (no console)
> > until most of the way through late_setup_arch().  Thus we need some way
> > to get an output console working early, then register the IRQ later.  I
> > don't know how to do that cleanly.
> I don't understand here.  This is already how it works: the console first 
> works by polling, then the IRQ *might* be enabled later.

   This is the way the normal 8250 serial driver works in the Linux
kernel, but I don't believe the same can be said for the ns16550 driver
in the hypervisor.  Polling would require that a timer periodically
check the UART for work.  I don't see that such a mechanism exists.
Therefore, an IRQ must be enabled by the ns16550 driver to get console
input.  Console output appears to be un-buffered and sent a character at
a time.  Therefore console output works even w/o interrupts.

   To get an IOSAPIC based interrupt working, we first need to get the
Global System Interrupt (GSI) for the device.  This effectively
describes the Redirection Table Entry (RTE) of the IOSAPIC the device
pulls for an interrupt.  The GSI doesn't really mean anything until we
use it to program the RTE on the IOSAPIC with an interrupt vector.  At
the point where we currently call ns16550_init(), we only know the GSI.
The processor side "IRQ" cannot be known until we discover the IOSAPIC
namespace and are able to register the GSI and translate it into an
interrupt vector via acpi_register_gsi().  The driver initialization
function ns16550_init() expects a data structure complete with the
processor interrupt vector for the device.  We don't know that at the
time it's currently called, nor does the ns16550 driver provide a way to
update the IRQ information later other than to call ns16550_init()
again.  Hope that helps,

        Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab


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

<Prev in Thread] Current Thread [Next in Thread>