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

To: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, "Williamson, Alex (Linux Kernel Dev)" <alex.williamson@xxxxxx>
Subject: RE: [Xen-ia64-devel] consoles, iosapics, and device interrupts
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Fri, 18 Nov 2005 09:11:09 -0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 18 Nov 2005 17:11:44 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXsLdtRINI3ZDmoQIi/66WSHbRwqAANOkZQ
Thread-topic: [Xen-ia64-devel] consoles, iosapics, and device interrupts
Another comment:

Should we use acpi.c from linux (either in xen/arch/ia64/linux
if no patches are required or xen/arch/ia64/linux-xen if
patches are required)?  The code in xen/arch/ia64/xen/acpi.c
is from an old version of linux (probably 2.6.7).

Dan 

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

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

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