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

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

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