Re: APIC version and 8-bit APIC IDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[ Putting everyone cc again and leaving maciej's reply intact for reference ]

Maciej W. Rozycki wrote:

The ID is 0x14 for Intel. But that is wrong for AMD CPUs. The actual Dual-Core


 Why can't hw designers ever get such things right?  Sigh...


Athlon CPUs we have report an APIC version of 0x10. Please refer to the start
of this thread.


Frankly, such a change implies a change to the inter-APIC communication protocol, so the major revision should have been bumped, like it happened for the I/O APIC (0x20); I hope they do not worry of changing the design so many times they run out of numbers! Thus none of the implementers has done their job properly, but for Intel there is at least some change, while for AMD there seems no generic way of determining that -- 0x10 implies a "traditional" integrated APIC as implemented in Pentium in 1995, using a three-wire serial bus for communication...

Perhaps a variable should be added holding the "architectural revision" of the APIC subsystem, set up by the early CPU/APIC initialization code and used from there on instead of direct references to the version register as implemented in the hardware. It does not have to be based on what hardware uses, e.g.:

- 0: no APIC,

- 1: 82489DX -- communication using a five-wire inter-APIC bus, 8-bit physical ID, 32-bit logical ID, etc.,

- 2: Pentium-style -- communication using a three-wire inter-APIC bus, 4-bit physical ID, 8-bit logical ID, etc.,

- 3: P4-style -- communication using the system bus, 8-bit physical ID, 8-bit logical ID, etc.

AMD has their HyperTransport bus, which is yet a different thing.

According to what AMD told us, all K8 CPUs support 8-bit APIC IDs ("extended APIC IDs" in their speak), but they are only enabled "when both ApicExtId and ApicExtBrdCst in the HyperTransport Transaction Control Register are set".

As we cannot read PCI config space at APIC configuration time, my suggestion would be something like

unsigned char phys_apic_id_mask(int apic_version)
        if (apic_version < 0x10 || apic_version >= 0x14 ||
		(boot_cpu_data.vendor == X86_VENDOR_AMD &&
         	 boot_cpu_data.family >= 0x0f))
		return 0xff;
	else
		return 0x0f;
}

That would assume that no BIOS is so stupid to set APIC IDs >0xf and at the same time forget to enable the respective bits in the HyperTransport Transaction Control Register.

I do not oversee whether boot_cpu_data is initialized when the APIC IDs need to be tested/masked, but somebody else certainly does.



Anyway, I understand that you agree this does not belong into the subarch
code?


That's CPU/chipset specific indeed. It shouldn't really depend on the platform these are used in. Exceptions, if any, can be handled on a case by case basis.

  Maciej

Regards
Martin

--
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1        mailto:[email protected]
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux