OSDev.org

Well...Does everyone know, how many HT-Threads per processor and how many processors per CPU are at most possible for system developers? Does any specification say anything about this? Which specifications?

EDIT: Do ACPI tables as MPS tables declare every processor?

Thanks
Noooooooooooooos

Hi,



In theory, the only limit is the number of APIC IDs (it's an 8-bit ID and one ID needs to be used by an I/O APIC, so you could have 255 logical CPUs in one core, or a 255 cores in a physical CPU without hyper-threading).

In practice, Intel haven't made a CPU with more than 2 logical CPUs per core yet and I'm not expecting to see more than 2 logical CPUs per core in the next 8 years at least. Nobody has made an (80x86) CPU with more than 8 cores yet, but I'm expecting 16-core CPUs within the next 2 years....



The MPS tables should not list additional logical CPUs, and the MPS tables you get from Bochs are buggy/wrong. ACPI always lists all logical CPUs.


Cheers,

Brendan

Well...And when I want to know which logical processor belongs to which CPU with ACPI tables I have a problem.

ACPI tables command the platform firmware to list the first logical processor of each of the indvdiual multi-threaded processors in the MADT before listing any of the second logical processors. And this approach should be used for all successive logical processors.

But how can I use this informations when I don't know the border between the first logical processors and the second logical processors? It's possible that this border is at any place in the table...


Thanks
Nooooooooos

Hi,



As you've noticed, the APIC MADT is useless for determining which chip and which core each logical CPU belongs to.

Fortunately this information can be derived from data returned by CPUID - see the algorithm described in Intel's System Programming Guide (it might be section "7.7.5 Identifying Logical Processors in an MP System", but my hardcopy is getting a little elderly and it may have been re-numbered since)...

The general idea is to convert "number of cores in the chip" and the "number of logical CPUs in the chip" into masks and a "shift count" that can be used on the APIC ID to find the logical CPU number within the core, the logical CPU number within the chip, and core number within the chip.

Note: In this case AMD CPUs aren't compatible with Intel CPUs. For Intel, "number of cores in the chip - 1" is returned by CPUID = 0x00000004, while for AMD it's returned by CPUID = 0x80000008. For AMD there's also something about a "CmpLegacy" flag that I can't quite remember, and it's possible there's other differences I've forgotten (my "sleep meter" is saying "empty" at the moment).


Cheers,

Brendan

Well...As specified in ACPI the OS has to use the XSDT Tables if they are present...
But I don't support Longmode in my OS and I want to use RSDT tables...So do I have to support only ACPI Version 2 or can I support Version 3 and simply use the RSDT though there is a XSDT?

Then I think I found a bug in Brendans BIOS...I discovered that I have to use Version 2 of ACPI to get a RSDT. But i only get a functional RSDT when I have just enabled Version 2 and had an other Version before...If I try it with Version 2 a second time I only get a RSDT wich has at its entries for other DescriptionHeaders the value of zero...

EDIT:
Is assumption, that MPS tables list every CPU and every CPU core, but no additional logial processors (beside the first logical processor who is also the core) right?

Cheers
Noooooooooos

Hi,



Even though you dont support long mode, long mode and the XSDT have nothing to do with each other and you should still use the XSDT.

However, because the XSDT uses 64-bit pointers it's theoretically possible that one or more XSDT entries point to a table that can't be accessed with 32-bit addressing. This is extremely unlikely for 80x86 - usually the RSDT and the XSDT both contain pointers that point to the same tables that are always below 4 GB (it's only really Itanium systems that need the 64-bit pointers). Just to be safe, my OS scans the XSDT to find out if any of it's entries point to anything above 4 GB, and then use the XSDT if it doesn't. If there is no XSDT or if it contains entries that point to something above 4 GB then I use the RSDT.



Doh - thanks

I think I've found and fixed the problem. At line 355 in "common/acpi/init.asm" it should be "mov edi,[dword EBDA_ADDRESS+EBDA_ACPI_RSDToffset]" rather than "mov [dword EBDA_ADDRESS+EBDA_ACPI_RSDToffset],edi".

Note: There is another bug in my BIOS - it uses AMD's method of determining cores and logical CPUs, which gives wrong results if Bochs is emulating Intel CPUs. The result is that when Bochs is emulating Intel CPUs it thinks there's one logical CPU per core, even if there's more, and you end up with all CPUs listed in the MPS tables. For ACPI's APIC table, my BIOS also never sorts the list (with the first logical CPU in each core before additional logical CPUs in each core). This is because it's a pain in the neck (and mostly useless anyway).




That's correct (except when using my BIOS with Bochs emulating Intel CPUs due to the bug in my BIOS that I mentioned above).


Cheers,

Brendan

Thanks...Now the BIOS works fine...

But how do you get Bochs to emulate a AMD CPU? I know neither of a config option nor of a compile option for this...Even if there is a compile option I'm not able to compile Bochs myself for Windows....


Cheers
Nooooooooooos

Hi,



There's different methods depending on which version of Bochs you're using. For the latest version you'd enable 3DNow. For older versions I think you'd use "family = 6" and enable 64-bit support, but I can't quite remember (you could check "bochs/cpu/cpuid.cc" to see which options work for the version you've got).

Note: Bochs (and Qemu) are never a 100% accurate emulation - typically very low level things (like instruction timings, MSRs, performance monitoring counters, caches and the memory controller) aren't necessarily implemented or implemented accurately. For example, you'll probably end up with something like a modern AMD CPU using an old Pentium (i440FX) chipset with an external northbridge instead of the internal memory controller and without any of the hyper-transport configuration registers. For normal code designed for "generic 80x86" (including normal OSs) this doesn't matter, but for firmware (LinuxBIOS) and other "hardware specific" code it may be a problem.



Welcome to the world of open source software - either use Linux (e.g. a Knoppix boot CD might work), or use Cygwin (a Linux compatability layer and GNU toolchain for Windows), or use whatever "native Windows" toolchain Bochs supports for Windows (Visual C++ I think, but you might need some Unix style tools, like autoconf and bash, from Cygwin - I've never tried it). Don't you just wish someone would invent a portable language *and* a portable toolchain and libraries to go with it?


Cheers,

Brendan

Hmmm...ok
I'm not sure if I've found an other bug in your BIOS...When I run your with ACPI Version 3 I get in the Revision Byte of the RSDP structure a value of 0x3 instead of the specified 0x2...

EDIT:
I also get on a AMD compiled Version of Bochs (checked by CPUID) only one core (BSP) in the MPS tables. I've Bochs configured with "cpu: count=1:2:2"


Cheers
Nooooooooooos

personally I'd like to have a 256x core 486-equivalent cpu, remove the multiple pipelines, making each core single-issue to squeeze as much cores into the same chip as possible, would make for a kick-@$$ raytracing renderfarm on-a-chip.

oh wait ... that's basically how GPGPU works

you can guess where AMD is going by buying ATI, and intel has something in the works about a chip including a full-feature controller core along with multiple dumbed down worker cores (a cell processor a la intel sauce ...)

hopefully, soon the 3d accelerator cards will be a thing of the past and we'll go back to software rendering with a simple 2D card for final output.

it still amazes me how creative lab can still sell "hardware accelerated" audio mixer cards when current cpus are much faster at software mixing than shoving X audio streams thru the PCI bus (express or not).