From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
Date: Fri, 25 Jan 2013 09:54:16 +0000
From: p9 newbie <rgandhasri@gmail.com>
Message-ID: <5b45e99b-c119-48f2-a727-3e780c229337@googlegroups.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
References: <a8717927-4f79-4636-a5b0-6510adf1258c@googlegroups.com>,
	<7019dab896b2c7e4d81c495a49f9fe62@brasstown.quanstro.net>
Subject: Re: [9fans] plan9: how to get irq to mach routing
Topicbox-Message-UUID: 0ea74c90-ead8-11e9-9d60-3106f5b1d025

Thanks for the detailed explanation Eriq. I couldn't find a pci binary that=
 supported -m option.
I have=20
# 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:
>=20
> > Hi,
>=20
> >=20
>=20
> > I would like to retrieve what IRQs are routed to what Machs (or
>=20
> > lapics).  I dumped IOAPIC's Redirection Table entries, but Destination
>=20
> > bits [63:48] are always '0xFF'.  Is there way to determine the routing
>=20
> > between IRQs and Machs/LAPICs serving them?.  One rudimentary way I
>=20
> > tried is that, in the interrupt service routine I accessed the 'm'
>=20
> > (Mach *) external variable to figure the routing between the IRQ and
>=20
> > and the Mach..  Wondering if there is a better way.  (for all legacy,
>=20
> > msi and msi-x interrupt types)
>=20
>=20
>=20
> leaving 8259 interrupts to the side, in a system using apics, there are
>=20
> four potential sources of interrupts for a processor
>=20
> - processor traps,
>=20
> - the lapic.  1 lapic attached to each processor
>=20
> - i/o apics
>=20
> - device sending an msi/msi-x interrupt.
>=20
>=20
>=20
> obviously lapic interrupts (such as the clock timer) and traps
>=20
> (such as #PF) are handled by the processor that generated them.
>=20
> in flat or cluster mode, external interrupts are usually routed to
>=20
> the "lowest priority" processor.  in physical mode, a particular
>=20
> processor is targeted.  msi reuses the same logic.
>=20
>=20
>=20
> the distribution uses physical addressing.  this means that interrupt
>=20
> =CE=B9 always targets processor p.  so the high bits should
>=20
> match the processor picked.  see
>=20
> 	/n/sources/plan9/sys/src/9/pc/mp.c:793
>=20
> 	/n/sources/plan9/sys/src/9/pc/mp.c:824
>=20
> i have not run this code to check, but it doesn't look like it sets
>=20
> the redirection to broadcast.  (iirc, it's illegal to target a non-existe=
nt
>=20
> processor from an i/o apic.)
>=20
>=20
>=20
> i was having trouble with apics a few years ago due to the hardware
>=20
> and thus did the apic implementation described in the man page.
>=20
> this implementation supports flat, cluster & physical modes:
>=20
>=20
>=20
> 	http://www.quanstro.net/magic/man2html/3/apic
>=20
>=20
>=20
> there are a number of files in '#P' that should help you poke
>=20
> around such as '#P/mpirq' which prints out the vectors as
>=20
> programmed.
>=20
>=20
>=20
> nix uses the same implementation with msi, but only
>=20
> uses physical mode in round-robin fashion.  i need to
>=20
> merge these.  there's no reason for them to be different.
>=20
>=20
>=20
> here's an example from a machine with physical-mode
>=20
> vectors.  the i/o apic targets lapic 00 and 04. =20
>=20
> minooka;  cat '#P/mpvec' | grep -v '10000$'
>=20
>            8           1 0000000000000141
>=20
>            8           4 0400000000000161
>=20
>=20
>=20
> here are the processors so we can find them.
>=20
> (this format keeps changing.  don't depend on it.  :))
>=20
>=20
>=20
> minooka; cat '#P/mpapic'
>=20
> proc            0 00000000 00000000 00000000 be            0 0xfee00000
>=20
> proc            1 01000000 01000000 01000000  e            8 0xfee00000
>=20
> proc            2 02000000 02000000 02000000  e            1 0xfee00000
>=20
> proc            3 03000000 03000000 03000000  e            9 0xfee00000
>=20
> proc            4 04000000 04000000 04000000  e            2 0xfee00000
>=20
> proc            5 05000000 05000000 05000000  e           10 0xfee00000
>=20
> proc            6 06000000 06000000 06000000  e            3 0xfee00000
>=20
> proc            7 07000000 07000000 07000000  e           11 0xfee00000
>=20
> ioapic          8 00000000 00000000 00000000  e            0 0xfec00000
>=20
> ioapic          9 00000000 00000000 00000000  e            0 0xfec8a000
>=20
> proc           10 10000000 10000000 10000000  e            4 0xfee00000
>=20
> proc           11 11000000 11000000 11000000  e           12 0xfee00000
>=20
> proc           12 12000000 12000000 12000000  e            5 0xfee00000
>=20
> proc           13 13000000 13000000 13000000  e           13 0xfee00000
>=20
> proc           14 14000000 14000000 14000000  e            6 0xfee00000
>=20
> proc           15 15000000 15000000 15000000  e           14 0xfee00000
>=20
> proc           16 16000000 16000000 16000000  e            7 0xfee00000
>=20
> proc           17 17000000 17000000 17000000  e           15 0xfee00000
>=20
>=20
>=20
> so this is processor 0 and 4.  (that's not normally the case.  this
>=20
> machine is pretty easy.)
>=20
>=20
>=20
> for msi,
>=20
>=20
>=20
> minooka;  /mnt/term/386/bin/pci -m | grep 00000000fee
>=20
> #	flags	target addr	data		next ptr
>=20
> 0.31.2	0009	00000000fee05000	00004069	80
>=20
> 1.0.0	0181	00000000fee02000	00004051	50
>=20
> 1.0.1	0181	00000000fee03000	00004059	50
>=20
> 3.0.0	0081	00000000fee01000	00004049	44
>=20
>=20
>=20
> bits 16:12 are the target.  so we see that we've targeted lapic 1, 3, 2, =
5.
>=20
> (which are fortunately for this example, identity mapped.)
>=20
>=20
>=20
> - erik