> 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. The maximum number of cpus in xAPIC is 256, not 2^16. My array is indexed by Kernel ID. My array is refitted to the exact number of cpus after enumerating them, to save space.
El jue., 30 jul. 2020 a las 23:17, Jessica Clarke (<jrt...@jrtc27.com>) escribió: > 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 > >
