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

[Alex Williamson <alex.williamson@xxxxxx>]

On Thu, 2005-11-17 at 08:36 -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> First patch (hpsim_cons) committed.  I'll try to get the
> 8250 config removal out in the next round of config file
> changes.

   Ok, careful not to make the console unusable.  As you once mentioned
to me, getting the output twice is better than not at all.  Likewise,
getting the output twice is better than an output only console ;^)

> Any further thinking on the console input issue?

   I haven't had as much time to spend on it as I'd like.  Adding
iosapic support to the hypervisor isn't terribly difficult.  There are
several problems with setting up the interrupt though:
      * PCDP info is fairly unreliable for getting proper
        trigger/polarity data.  ACPI namespace would be preferred for
        non-PCI UARTs.  We don't currently start ACPI namespace, nor am
        I convinced we want to.
      * 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.
      * With all of the above hacked to defaults for my box, once I add
        the serial_init_postirq() call, the hypervisor locks up :(

I know I need to go look at the IRQ handler and add a filter for this
interrupt line (I think there may have been a patch to the ml to do
this), but I thought I'd better get up to speed on things like Bjerke's
thesis before I rock the boat too much.  A fall back polling mechanism
in ns16550 might be an easier first step.

   I also need to go back and further digest the threads Kevin
referenced, but I'm thinking we'll likely need to virtualize the IOSAPIC
RTEs to the domains.  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).  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 :(

        Alex  

-- 
Alex Williamson                             HP Linux & Open Source Lab


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