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

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

Sounds like good progress, but a couple comments:

I don't think we should put the ACPI namespace code into Xen/ia64.
IIRC, this is a *lot* of code and I don't think it is worth
adding it just so we can have console input to Xen
without going through Dom0.   I think the Cambridge Xen
team would agree...

Is it possible to have console input routed to Xen
through Dom0 via the virtual console?  This of course
will be worthless before Xen boots Dom0, or if Dom0 crashes.
But there really is limited value for direct console input
into Xen except for debugging -- and it is a potentially
big security hole.

Last, it might be worth promoting this discussion to
xen-devel as there might be some useful input from
Cambridge and the IBM Power port team.  Alex, could
you summarize the discussion to date and post it to
xen-devel for comment?

Dan

> -----Original Message-----
> From: Williamson, Alex (Linux Kernel Dev) 
> Sent: Friday, November 18, 2005 8:53 AM
> To: Tristan Gingold
> Cc: Magenheimer, Dan (HP Labs Fort Collins); 
> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-ia64-devel] consoles, iosapics, and device 
> interrupts
> 
> 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