* [9fans] plan9: how to get irq to mach routing @ 2013-01-24 10:00 p9 newbie 2013-01-24 16:22 ` erik quanstrom 0 siblings, 1 reply; 4+ messages in thread From: p9 newbie @ 2013-01-24 10:00 UTC (permalink / raw) To: 9fans Hi, I would like to retrieve what IRQs are routed to what Machs (or lapics). I dumped IOAPIC's Redirection Table entries, but Destination bits [63:48] are always '0xFF'. Is there way to determine the routing between IRQs and Machs/LAPICs serving them?. One rudimentary way I tried is that, in the interrupt service routine I accessed the 'm' (Mach *) external variable to figure the routing between the IRQ and and the Mach.. Wondering if there is a better way. (for all legacy, msi and msi-x interrupt types) Thanks rg ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9fans] plan9: how to get irq to mach routing 2013-01-24 10:00 [9fans] plan9: how to get irq to mach routing p9 newbie @ 2013-01-24 16:22 ` erik quanstrom 2013-01-25 9:54 ` p9 newbie 0 siblings, 1 reply; 4+ messages in thread From: erik quanstrom @ 2013-01-24 16:22 UTC (permalink / raw) To: 9fans On Thu Jan 24 05:09:23 EST 2013, rgandhasri@gmail.com wrote: > Hi, > > I would like to retrieve what IRQs are routed to what Machs (or > lapics). I dumped IOAPIC's Redirection Table entries, but Destination > bits [63:48] are always '0xFF'. Is there way to determine the routing > between IRQs and Machs/LAPICs serving them?. One rudimentary way I > tried is that, in the interrupt service routine I accessed the 'm' > (Mach *) external variable to figure the routing between the IRQ and > and the Mach.. Wondering if there is a better way. (for all legacy, > msi and msi-x interrupt types) leaving 8259 interrupts to the side, in a system using apics, there are four potential sources of interrupts for a processor - processor traps, - the lapic. 1 lapic attached to each processor - i/o apics - device sending an msi/msi-x interrupt. obviously lapic interrupts (such as the clock timer) and traps (such as #PF) are handled by the processor that generated them. in flat or cluster mode, external interrupts are usually routed to the "lowest priority" processor. in physical mode, a particular processor is targeted. msi reuses the same logic. the distribution uses physical addressing. this means that interrupt ι always targets processor p. so the high bits should match the processor picked. see /n/sources/plan9/sys/src/9/pc/mp.c:793 /n/sources/plan9/sys/src/9/pc/mp.c:824 i have not run this code to check, but it doesn't look like it sets the redirection to broadcast. (iirc, it's illegal to target a non-existent processor from an i/o apic.) i was having trouble with apics a few years ago due to the hardware and thus did the apic implementation described in the man page. this implementation supports flat, cluster & physical modes: http://www.quanstro.net/magic/man2html/3/apic there are a number of files in '#P' that should help you poke around such as '#P/mpirq' which prints out the vectors as programmed. nix uses the same implementation with msi, but only uses physical mode in round-robin fashion. i need to merge these. there's no reason for them to be different. here's an example from a machine with physical-mode vectors. the i/o apic targets lapic 00 and 04. minooka; cat '#P/mpvec' | grep -v '10000$' 8 1 0000000000000141 8 4 0400000000000161 here are the processors so we can find them. (this format keeps changing. don't depend on it. :)) minooka; cat '#P/mpapic' proc 0 00000000 00000000 00000000 be 0 0xfee00000 proc 1 01000000 01000000 01000000 e 8 0xfee00000 proc 2 02000000 02000000 02000000 e 1 0xfee00000 proc 3 03000000 03000000 03000000 e 9 0xfee00000 proc 4 04000000 04000000 04000000 e 2 0xfee00000 proc 5 05000000 05000000 05000000 e 10 0xfee00000 proc 6 06000000 06000000 06000000 e 3 0xfee00000 proc 7 07000000 07000000 07000000 e 11 0xfee00000 ioapic 8 00000000 00000000 00000000 e 0 0xfec00000 ioapic 9 00000000 00000000 00000000 e 0 0xfec8a000 proc 10 10000000 10000000 10000000 e 4 0xfee00000 proc 11 11000000 11000000 11000000 e 12 0xfee00000 proc 12 12000000 12000000 12000000 e 5 0xfee00000 proc 13 13000000 13000000 13000000 e 13 0xfee00000 proc 14 14000000 14000000 14000000 e 6 0xfee00000 proc 15 15000000 15000000 15000000 e 14 0xfee00000 proc 16 16000000 16000000 16000000 e 7 0xfee00000 proc 17 17000000 17000000 17000000 e 15 0xfee00000 so this is processor 0 and 4. (that's not normally the case. this machine is pretty easy.) for msi, minooka; /mnt/term/386/bin/pci -m | grep 00000000fee # flags target addr data next ptr 0.31.2 0009 00000000fee05000 00004069 80 1.0.0 0181 00000000fee02000 00004051 50 1.0.1 0181 00000000fee03000 00004059 50 3.0.0 0081 00000000fee01000 00004049 44 bits 16:12 are the target. so we see that we've targeted lapic 1, 3, 2, 5. (which are fortunately for this example, identity mapped.) - erik ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9fans] plan9: how to get irq to mach routing 2013-01-24 16:22 ` erik quanstrom @ 2013-01-25 9:54 ` p9 newbie 2013-01-25 15:31 ` erik quanstrom 0 siblings, 1 reply; 4+ messages in thread From: p9 newbie @ 2013-01-25 9:54 UTC (permalink / raw) To: 9fans Thanks for the detailed explanation Eriq. I couldn't find a pci binary that supported -m option. I have # pci -help usage: pci [-vb] [vid/did ...] Thanks rg On Thursday, January 24, 2013 8:22:16 AM UTC-8, erik quanstrom wrote: > On Thu Jan 24 05:09:23 EST 2013, rgandhasri@gmail.com wrote: > > > Hi, > > > > > > I would like to retrieve what IRQs are routed to what Machs (or > > > lapics). I dumped IOAPIC's Redirection Table entries, but Destination > > > bits [63:48] are always '0xFF'. Is there way to determine the routing > > > between IRQs and Machs/LAPICs serving them?. One rudimentary way I > > > tried is that, in the interrupt service routine I accessed the 'm' > > > (Mach *) external variable to figure the routing between the IRQ and > > > and the Mach.. Wondering if there is a better way. (for all legacy, > > > msi and msi-x interrupt types) > > > > leaving 8259 interrupts to the side, in a system using apics, there are > > four potential sources of interrupts for a processor > > - processor traps, > > - the lapic. 1 lapic attached to each processor > > - i/o apics > > - device sending an msi/msi-x interrupt. > > > > obviously lapic interrupts (such as the clock timer) and traps > > (such as #PF) are handled by the processor that generated them. > > in flat or cluster mode, external interrupts are usually routed to > > the "lowest priority" processor. in physical mode, a particular > > processor is targeted. msi reuses the same logic. > > > > the distribution uses physical addressing. this means that interrupt > > ι always targets processor p. so the high bits should > > match the processor picked. see > > /n/sources/plan9/sys/src/9/pc/mp.c:793 > > /n/sources/plan9/sys/src/9/pc/mp.c:824 > > i have not run this code to check, but it doesn't look like it sets > > the redirection to broadcast. (iirc, it's illegal to target a non-existent > > processor from an i/o apic.) > > > > i was having trouble with apics a few years ago due to the hardware > > and thus did the apic implementation described in the man page. > > this implementation supports flat, cluster & physical modes: > > > > http://www.quanstro.net/magic/man2html/3/apic > > > > there are a number of files in '#P' that should help you poke > > around such as '#P/mpirq' which prints out the vectors as > > programmed. > > > > nix uses the same implementation with msi, but only > > uses physical mode in round-robin fashion. i need to > > merge these. there's no reason for them to be different. > > > > here's an example from a machine with physical-mode > > vectors. the i/o apic targets lapic 00 and 04. > > minooka; cat '#P/mpvec' | grep -v '10000$' > > 8 1 0000000000000141 > > 8 4 0400000000000161 > > > > here are the processors so we can find them. > > (this format keeps changing. don't depend on it. :)) > > > > minooka; cat '#P/mpapic' > > proc 0 00000000 00000000 00000000 be 0 0xfee00000 > > proc 1 01000000 01000000 01000000 e 8 0xfee00000 > > proc 2 02000000 02000000 02000000 e 1 0xfee00000 > > proc 3 03000000 03000000 03000000 e 9 0xfee00000 > > proc 4 04000000 04000000 04000000 e 2 0xfee00000 > > proc 5 05000000 05000000 05000000 e 10 0xfee00000 > > proc 6 06000000 06000000 06000000 e 3 0xfee00000 > > proc 7 07000000 07000000 07000000 e 11 0xfee00000 > > ioapic 8 00000000 00000000 00000000 e 0 0xfec00000 > > ioapic 9 00000000 00000000 00000000 e 0 0xfec8a000 > > proc 10 10000000 10000000 10000000 e 4 0xfee00000 > > proc 11 11000000 11000000 11000000 e 12 0xfee00000 > > proc 12 12000000 12000000 12000000 e 5 0xfee00000 > > proc 13 13000000 13000000 13000000 e 13 0xfee00000 > > proc 14 14000000 14000000 14000000 e 6 0xfee00000 > > proc 15 15000000 15000000 15000000 e 14 0xfee00000 > > proc 16 16000000 16000000 16000000 e 7 0xfee00000 > > proc 17 17000000 17000000 17000000 e 15 0xfee00000 > > > > so this is processor 0 and 4. (that's not normally the case. this > > machine is pretty easy.) > > > > for msi, > > > > minooka; /mnt/term/386/bin/pci -m | grep 00000000fee > > # flags target addr data next ptr > > 0.31.2 0009 00000000fee05000 00004069 80 > > 1.0.0 0181 00000000fee02000 00004051 50 > > 1.0.1 0181 00000000fee03000 00004059 50 > > 3.0.0 0081 00000000fee01000 00004049 44 > > > > bits 16:12 are the target. so we see that we've targeted lapic 1, 3, 2, 5. > > (which are fortunately for this example, identity mapped.) > > > > - erik ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9fans] plan9: how to get irq to mach routing 2013-01-25 9:54 ` p9 newbie @ 2013-01-25 15:31 ` erik quanstrom 0 siblings, 0 replies; 4+ messages in thread From: erik quanstrom @ 2013-01-25 15:31 UTC (permalink / raw) To: 9fans On Fri Jan 25 04:59:21 EST 2013, rgandhasri@gmail.com wrote: > Thanks for the detailed explanation Eriq. I couldn't find a pci binary that supported -m option. > I have > # pci -help > usage: pci [-vb] [vid/did ...] there aren't any long options in plan 9, so the old way to say that was "pci -?". otherwise that should be parsed as 4 options, all of which might be valid. i put /n/sources/contrib/quanstor/8.pci up on sources. the man page is http://www.quanstro.net/magic/man2html.8/pci it requires that the caller be allowed to read $#/pci/$dev^raw. this seems safe enough. - erik ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-01-25 15:31 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-01-24 10:00 [9fans] plan9: how to get irq to mach routing p9 newbie 2013-01-24 16:22 ` erik quanstrom 2013-01-25 9:54 ` p9 newbie 2013-01-25 15:31 ` erik quanstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).