Confused by local APIC addressing in setup_IO_APIC_irqs()

Confused by local APIC addressing in setup_IO_APIC_irqs()

[Martin J. Bligh]

It seems to me that we're stuffing a 32 bit bitmask into an
8 bit register ... which seems very odd. Either I don't understand
this properly (probable ;-)) or something's wrong ... can anyone
shed some light on this for me?

It looks like we do this in arch/i386/kernel/io_apic.c (2.4.x):

-----------------------------------------

#define TARGET_CPUS cpu_online_map

void __init setup_IO_APIC_irqs(void)
{
        struct IO_APIC_route_entry entry;
....
entry.dest.logical.logical_dest = TARGET_CPUS;
....
                io_apic_write(apic, 0x11+2*pin, *(((int *)&entry)+1));
                io_apic_write(apic, 0x10+2*pin, *(((int *)&entry)+0));

---------------------------------------------

But ....

struct IO_APIC_route_entry {
...
    union {
....
            struct { __u32
                    __reserved_1    : 24,
                    logical_dest    :  8;
            } logical;
    } dest;

---------------------------------------------

But cpu_online map seems to be a 32 bit bitmask of which
CPUs are online .... are we stuffing this directly into an 8-bit
logical desitination register?

Ironically, if I'm understanding this right, it kind of works anyway
for most systems - the low nibble of the logical ID is a bitmask
anyway, so it works normally for up to 4 way. For 8 way or more,
the high nibble will be set to 1111, which is the broadcast cluster ID,
so it'll direct interrupts anywhere .... but I can't believe that was
intentional ;-) For a start, a 7 way system would send to some
non-existant cluster ID ....

Any insights would be much appreciated,

Thanks,

Martin.

Re: Confused by local APIC addressing in setup_IO_APIC_irqs()

[Martin J. Bligh]

> But cpu_online map seems to be a 32 bit bitmask of which
> CPUs are online .... are we stuffing this directly into an 8-bit
> logical desitination register?
>
> Ironically, if I'm understanding this right, it kind of works anyway
> for most systems - the low nibble of the logical ID is a bitmask
> anyway, so it works normally for up to 4 way. For 8 way or more,
> the high nibble will be set to 1111, which is the broadcast cluster ID,
> so it'll direct interrupts anywhere .... but I can't believe that was
> intentional ;-) For a start, a 7 way system would send to some
> non-existant cluster ID ....

Damn ... sorry - figured this out. The way Linux is doing it will work
up to 8 CPUs. I'd forgotten that earlier on in my changes I'd switched
the CPUs local APICs from FLAT logical addressing mode to
CLUSTERED logical addressing mode. I need to switch the IO APIC code
to match ...

Thanks,

Martin.