On Fri, 7 Mar 2003, Martin J. Bligh wrote:
> Actually, I think your first patch is correct. TARGET_CPUS seems like the
> wrong thing to be changing (for example, if we take a CPU offline later)
> However, doesn't this:
Not to mention if we take an interrupt (say pit doing timer ints) and it
gets sent to one of the still yet to boot cpus? (Although we're so close
to bringing them up it really doesn't matter).
> > +/*
> > + * This function currently is only a helper for the i386 smp boot process where
> > + * we need to reprogram the ioredtbls to cater for the cpus which have come online
> > + * so mask in all cases should simply be TARGET_CPUS
> > + */
> > +void __devinit set_ioapic_logical_dest (unsigned long mask)
> > +{
> > + struct IO_APIC_route_entry entry;
> > + unsigned long flags;
> > + int apic, pin;
> > +
> > + spin_lock_irqsave(&ioapic_lock, flags);
> > + for (apic = 0; apic < nr_ioapics; apic++) {
> > + for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) {
> > + *(((int *)&entry)+0) = io_apic_read(apic, 0x10+pin*2);
> > + *(((int *)&entry)+1) = io_apic_read(apic, 0x11+pin*2);
> > + entry.dest.logical.logical_dest = mask;
> > + io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&entry) + 0));
> > + io_apic_write(apic, 0x11 + 2 * pin, *(((int *)&entry) + 1));
> > + }
> > +
> > + }
> > + spin_unlock_irqrestore(&ioapic_lock, flags);
> > +}
>
> do more or less the same as set_ioapic_affinity? And even if not, don't
> you have to do "mask << 24" instead of "mask" ... or am I just confused?
union { struct { __u32
__reserved_1 : 24,
physical_dest : 4,
__reserved_2 : 4;
} physical;
struct { __u32
__reserved_1 : 24,
logical_dest : 8;
} logical;
} dest;
Yes. But here we're lucky here because IO_APIC_route_entry is a nicely
setup struct, all we need to do is put in the mask, for SMP boxes
with over 8 cpus we'd stuff 0xf with all the magic being in TARGET_CPUS
for each sub architecture.
Thanks,
Zwane
-- function.linuxpower.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 07 2003 - 22:00:36 EST