On 30 Jul 2020, at 22:12, Richard Braun <rbr...@sceen.net> wrote: > On Thu, Jul 30, 2020 at 10:09:01PM +0100, Jessica Clarke wrote: >>> It's physically memory mapped to the local APIC address space, but >>> because of that, it's also not optimal. All systems I know use a scheme >>> similar to TLS, i.e. using the fs or gs segment register, to fetch >>> a per-CPU structure and from it, per-CPU data. This avoids relying on >>> hardware running at a lower frequency than the CPU. >> >> You need to do that anyway if you want any guarantees over _what_ the >> IDs are (normally you want 0 for the BSP, 1 to N-1 for the APs). > > Not really. You can build a CPU ID table on the BSP, and associate CPU IDs > with all local APIC IDs discovered, and use that look-up table later > to obtain a CPU ID from the local APIC ID of the CPU running the code. > It's just too slow compared to using a segment register.
Well, yes, though you probably don't want to be using a fancy hash table in such low-level code, so you'd either have an array of 2^16 CPU IDs which is a bit absurd (or at least _used_ to be, these days it's not that big) or just do some kind of search. I kind of ruled both out from the get-go because they're too absurd, especially on other systems where the APIC ID equivalent is 32-bit or 64-bit and you might have hundreds of cores' IDs to search through to find your own. Jess
