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

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Jeudi 17 Novembre 2005 18:15, Alex Williamson a Ãcrit :
> 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 ;^)
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.

> > Any further thinking on the console input issue?
I made tries a few weeks ago.

>    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.
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.

>       * 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.

> 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. 
Sure.

> 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.

> 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 ?

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).

Tristan.

Attachment: xen-console2.diff
Description: Text Data

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