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

[Alex Williamson <alex.williamson@xxxxxx>]

On Fri, 2005-11-18 at 13:52 +0200, Tristan Gingold wrote:
> Just be to clear:  there are currently 3 outputs because there are 3 consoles:
> * hpsim cons.
> * Xen console.
> * Linux serial.
> If Xen console is used as input too, you have to disable Linux serial console.

   Right, that's what I'm hoping we can get to since that matches x86
and I believe it's the only way to get the ^A switching between xen and
dom0.  It would be nice to hide the physical UART the Xen console uses
from xenlinux... not sure how best to do that.

> >       * IOSAPICs are parsed late in the hypervisor bootup.  There's a
> >         timing issue with setting up the RTE at the right point in the
> >         boot.  We can call ns16550_init() more than once for a port, but
> >         that's pretty ugly.
> I don't agree.  The serial output is enabled early using pooling.  Interrupts
> can be enabled later, after parsing IOSAPICS and when interrupts can be
> enabled.

   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.

> >       * With all of the above hacked to defaults for my box, once I add
> >         the serial_init_postirq() call, the hypervisor locks up :(
> I successed here.

   Great!

> > This would probably entail creating a custom MADT
> > for each privileged domain exporting an RTE namespace that requires
> > hypervisor callbacks to interact with (the IOSAPIC windowing access
> > needs to be serialized somewhere). 
> I don't think we need to create a custom MADT.

   Yeah, the more I think about it, maybe the domains don't need to know
about that.  They can use hypercalls with only the GSI info.

> > Unfortunately, if we are to carve up
> > RTEs based on PCI devices, we're going to need to get at the PCI Routing
> > Tables (_PRTs) in ACPI namespace.  Getting ACPI namespace running
> > probably isn't that difficult, but it's a huge mass of code to add to
> > the hypervisor :(
> Here is my proposal: the hypervisor handle IOSAPIC like linux is currently 
> doing.  Dom0 linux (or dom-driver linuxes) see and parses MADT, but does not 
> directly modify IOSAPIC: it does an hypercall, which may fails if the 
> interrupt is already allocated by the hypervisor (or another domain).  I 
> think this approach is simple and follows the transparent para-virtualization 
> spirit.
> 
> Should I go ?

   Yes, please, sounds like a good start.  After contemplating the MADT
issue some more, what will dom0 do w/ the IOSAPICs?  We're going to need
extra xen specific kludges in xenlinux to see IOSAPICS in the MADT and
ignore them.  There are no flags in the IOSAPIC MADT entry to mark it
disabled like there is for the local APIC.  I think maybe we should just
remove the IOSAPICs from the MADT to avoid xenlinux registering support
for them.

> Here (again ?) is the patch to enable Xen console I/O.  It is a little bit 
> old, but worked once.  I did not submit it because it required an hack: dom0 
> linux should ignore irq 3 (used by Xen serial).

   This looks like it has all the base irq code that I was missing,
however, iosapic.[ch] are not included in the diff.  I also don't see
where ns16550_com.irq is set.  Does it get past serial_init_postirq()
only because the first test in ns16550_init_postirq() doesn't find an
irq and exits?  Please keep me up to date on your progress, I'd
certainly like to help get this working.  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