From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: pvops-2.6.32 - Interrupt routing problem Date: Tue, 16 Mar 2010 22:05:49 -0400 Message-ID: <20100317020549.GA1414@phenom.dumpdata.com> References: <4B9D0726.3060304@goop.org> <20100314161750.GA7790@wavehammer.waldi.eu.org> <20100315101126.GA24650@wavehammer.waldi.eu.org> <20100315211459.GA9314@wavehammer.waldi.eu.org> <20100316013114.GD7622@phenom.dumpdata.com> <20100316081832.GA20502@wavehammer.waldi.eu.org> <20100316153216.GB28821@phenom.dumpdata.com> <20100316182053.GA2258@wavehammer.waldi.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20100316182053.GA2258@wavehammer.waldi.eu.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bastian Blank Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Keir Fraser , "Zhang, Xiantao" List-Id: xen-devel@lists.xenproject.org On Tue, Mar 16, 2010 at 07:20:53PM +0100, Bastian Blank wrote: > On Tue, Mar 16, 2010 at 11:32:16AM -0400, Konrad Rzeszutek Wilk wrote: > > I wish you had included the whole serial console for Xen boot. > > That was the intention but I had to run. Here is it (slightly > annotated). > > > I am > > curious to at what stage the pin 14 of the IOAPIC is set. Is it set by Xen > > hypervisor initially (don't think so), > > No, the entries on the first IO-APIC for the devices in question are > completely bogus in the initial printout. Unmasked but edge driven. I am going to need your help here. I *think* the issue is that Xen parses the MADT table, which makes the assumption that the ISA interrupt vectors will usually be identity-mapped into the first 16 I/O APIC sources (and the INT_SRC_OVR are used to override those IO APIC pins with new entries). I think it does this: acpi_parse_madt_ioapic_entries calls mp_config_acpi_legacy_irqs: .. snip .. intsrc.mpc_irqflag = 0; /* Conforming */ Which assumes that it is edge, high. I think if you fix this line: 1089 Dprintk("Int: type %d, pol %d, trig %d, bus %d, irq %d, " to do a printk we will see that your pin 14 is programmed to edge(0), high(0). Which by itself is exactly the same thing Linux kernel in baremetal does. But that does not explain why you can't reprogram it. There is that check you subverted which sets this: mp_ioapic_routing[ioapic].pin_programmed[idx] |= (1< > or is there another piece of code > > in the pv-ops that iterates over the 0-15 IRQs and sets them to the > > legacy trigger/level? > > Before the initialisation of the console, the kernel seem to set pins 5 > to 15 on the first IO-APIC to all edge driven. Yeah, the more I look up data sheets that seems to be right way. > > > When you printed out the IOAPIC information, did the Xen one (in the > > hypervisor, when you did apic=debug during boot) have pin 14 set to the > > wrong mode? > > Yes. Which is OK, b/c when APIC turns on, then you should be able to program it. That is what Linux on baremetal does. > > > Or was it later when the pv-ops kernel booted that the pin 14 was set > > incorrectly? > > The kernel sets it to this values again. You mean it sets it to level (1), low (1) for pin 14 and 5.