The Place to Start for Operating System Developers
http://f.osdev.org/
(A complete rewrite of bochs with x2APIC support, that is.)Adding x2apic to Bochs should be a couple of days.bewing wrote:I'm working on it.
A basic version of it should be ready for alpha testing in a couple weeks. But adding the NUMA stuff to it may take another month after that.
Bochs GUI is integrated to Bochs CVS and fairly tested. Download latest CVS snapshot and run.kmtdk wrote:well
yea
it will be funny ( and since many are trying to implent it now. ...)
[ how are you doing with bochs gui ???(know this should be Privat), and ect if i can have a copy (i got lost in my own compilingen, and stopped)]
KMT dk
Awesome. I'd be happy to alpha test.bewing wrote:I'm working on it.
A basic version of it should be ready for alpha testing in a couple weeks. But adding the NUMA stuff to it may take another month after that.
65535 CPUs is fun but the same rewrite is not needed to wait until you (or me) code x2apic.bewing wrote:Good, because I may well need to tap your expertise (and Brendan's) -- or get example code from you to do my initial debugging. I'm concentrating first on other devices (such as the hard disk) that I know fairly well, but my knowledge of x2APIC is mighty iffy. I'm intending to max out at modeling 65,536 CPUs (multithreaded, one CPU per thread), so an x2APIC model is necessary.
In the past I've run large numbers of CPUs in Bochs (> 64 if I remember right) without any performance problems, and you've done a lot of work to improve performance since. The current Bochs code should handle 255 CPUs, as long as the user realizes that each CPU will be 255 times slower than it would be if Bochs only emulated one CPU.stlw wrote:The Xapic interface in Bochs today allows up to 256 CPUs - anyway nobody could run all of them in the same machine without multithreading.
I agree, the limitation of 8 CPUs in Bochs is quite artificial. Nothing in Bochs itself limits you for this particular value.Brendan wrote:Hi,
In the past I've run large numbers of CPUs in Bochs (> 64 if I remember right) without any performance problems, and you've done a lot of work to improve performance since. The current Bochs code should handle 255 CPUs, as long as the user realizes that each CPU will be 255 times slower than it would be if Bochs only emulated one CPU.
Note: this is quite acceptable for someone who's testing how well their OS scales (lock contention, etc). Even if you need to run the emulator for 8 hours instead of 8 minutes, it's still far more practical than buying a real computer with a few hundred CPUs...
Brendan
Maybe a bochs bios patch could fix this? It just seems like you would need to change where ACPI and MP tables are allocated.stlw wrote: Anyway, even aftre complete Bochs code rewrite and parallelization of all CPUs it will not help you to increase their amount.
The bottleneck still in the BIOS.
From memory (and possibly wrong, but)...stlw wrote:I agree, the limitation of 8 CPUs in Bochs is quite artificial. Nothing in Bochs itself limits you for this particular value.Brendan wrote:In the past I've run large numbers of CPUs in Bochs (> 64 if I remember right) without any performance problems, and you've done a lot of work to improve performance since. The current Bochs code should handle 255 CPUs, as long as the user realizes that each CPU will be 255 times slower than it would be if Bochs only emulated one CPU.
Note: this is quite acceptable for someone who's testing how well their OS scales (lock contention, etc). Even if you need to run the emulator for 8 hours instead of 8 minutes, it's still far more practical than buying a real computer with a few hundred CPUs...
The limitation was added aftre Bochs BIOS started to become MP BIOS + ACPI BIOS.
The BIOS needed to know some kind of limitation for amount of entries in MP and ACPI tables, and the limit of 8 CPUs was choosen.
Choosen I could tell randomly.
Code: Select all
config.cc @ line 428
#define BX_CPU_PROCESSORS_LIMIT 255
#define BX_CPU_CORES_LIMIT 8
#define BX_CPU_HT_THREADS_LIMIT 4Code: Select all
config.h.in @ line 57
#define BX_MAX_SMP_THREADS_SUPPORTED 255Code: Select all
bochs.g @ line 359
#define MAX_LOGFNS 1024For up to 255 CPUs it costs 20 bytes per CPU, or about 5 KiB in the EBDA (or wherever the MP specification tables are placed), which shouldn't be a problem at all. If there's more than 255 CPUs, then the MP specification tables only support 8-bit APIC IDs and the best thing to do would be to skip the MP specification tables completely (they're mostly obsolete now anyway).stlw wrote:I suggest you to talk with Bochs BIOS experts to see how many CPUs actually Bochs BIOS could support (without overlapping tables at least).
I think there is no real problem to increase the number.
Of course now we're back to the original problem - statically defined structures being used to describe extremely flexible/configurable hardware. Basically the ACPI AML code (currently in the file "acpi-dsdt.hex") needs to be generated dynamically during boot, which is exactly what I told Bochs developers several years ago when I was writing my BIOS.Intel wrote:A.2.1 x2APIC Structure
The Processor X2APIC structure (type 9) is very similar to the processor local APIC structure (type 0). When using the X2APIC interrupt model, logical processors with APIC ID values of 255 and greater in the system are required to have a Processor X2APIC record and an ACPI Device object. OSPM does not expect the information provided in this table to be updated if the processor information changes during the lifespan of an OS boot. While in the sleeping state, logical processors are not allowed to be added, removed, nor can their X2APIC ID or x2APIC Flags change. When a logical processor is not present, the Processor X2APIC information is either not reported or flagged as disabled.
