Hi!
Maybe this is a really simple question but I didn't find the answer for it. So how can I tell bochs to support more than 8 cpu cores? As I see there's a BX_MAX_SMP_THREADS_SUPPORTED definition in config.h that is 8 by default. If I set the previous definition to 32 (for example) bochs simple failes to start.
Thanks,
giszo
More than 8 cores under bochs
Re: More than 8 cores under bochs
I can't really answer your question about Bochs but you should try your code under QEMU as well.
I have tested my SMP code under QEMU with 128 cores.
-Ian
I have tested my SMP code under QEMU with 128 cores.
-Ian
BareMetal OS - http://www.returninfinity.com/
Mono-tasking 64-bit OS for x86-64 based computers, written entirely in Assembly
Mono-tasking 64-bit OS for x86-64 based computers, written entirely in Assembly
Re: More than 8 cores under bochs
Unfortunately I can't install qemu to my Linux (gentoo) box because it requires GCC 3.x to compile and I have 4.x only That's why I'm using bochs and looking for a solutioniseyler wrote:I can't really answer your question about Bochs but you should try your code under QEMU as well.
I have tested my SMP code under QEMU with 128 cores.
-Ian
Re: More than 8 cores under bochs
Hi,
Then you'd need to look into the Bochs BIOS and see what it's limitations are - mostly the code that generates the MP Specification tables and ACPI tables. I used to use my own BIOS code, so I don't know if there's problems with the Bochs BIOS code or not.
I have tried this, and after installing GCC 3.4 and switching to the old version of GCC you can do "emerge qemu" and then switch back to a recent version of GCC. Qemu will compile/emerge without any errors this way, but that doesn't mean Qemu will actually run. In my case Qemu locked up while trying to start, but I'm not too sure if that was a problem with the USE flags or if it's because of some other problem (Qemu not liking the idea of being run as 64-bit code maybe). I also tried downloading the pre-built binaries of Qemu for Linux, but they failed to find shared libraries on my system.
Of course I wasn't too persistent. Mostly I was doing research into EFI at the time - trying to decide if it'd be worth the trouble writing an EFI bootloader for my OS, and hoping to find some way to test the code. After installing Qemu on Windows XP (a different computer) and finding that the EFI BIOS for Qemu doesn't work "as is", I did some research on Apple machines and/or recent Intel motherboards that support EFI and decided that EFI isn't mature enough (or well supported enough) for me to worry about at the moment; and once I stopped worrying about EFI I had no reason to continue trying to get Qemu to work.
Also note that for SMP, Qemu emulates each CPU for a fixed amount of time (e.g. first CPU for 10 ms, next CPU for 10 ms, next CPU for 10 ms, etc). Because of this the chance of finding race conditions, etc is extremely small because Qemu does a few million instructions on one CPU before any other CPUs do any instructions, which makes Qemu useless for a lot of SMP testing purposes.
Cheers,
Brendan
I haven't done this for a while (a year or 2) and a lot has probably changed since. Normally you'd need to change a few other things, like the ""#define MAX_LOGFNS" in Bochs.h and the "#define BX_MAX_TIMERS" in pcsystem.h so that the rest of Bochs can cope with the increase in CPUs. I'm also not sure how many CPUs the current APIC code can handle - originally the APIC code used a bitfield or something that was limited to about 32 CPUs, but that was rewritten.giszo wrote:Maybe this is a really simple question but I didn't find the answer for it. So how can I tell bochs to support more than 8 cpu cores? As I see there's a BX_MAX_SMP_THREADS_SUPPORTED definition in config.h that is 8 by default. If I set the previous definition to 32 (for example) bochs simple failes to start.
Then you'd need to look into the Bochs BIOS and see what it's limitations are - mostly the code that generates the MP Specification tables and ACPI tables. I used to use my own BIOS code, so I don't know if there's problems with the Bochs BIOS code or not.
For Gentoo, you can have several different versions of GCC installed at the same time and switch between them. For a quick description see this page.giszo wrote:Unfortunately I can't install qemu to my Linux (gentoo) box because it requires GCC 3.x to compile and I have 4.x only That's why I'm using bochs and looking for a solution
I have tried this, and after installing GCC 3.4 and switching to the old version of GCC you can do "emerge qemu" and then switch back to a recent version of GCC. Qemu will compile/emerge without any errors this way, but that doesn't mean Qemu will actually run. In my case Qemu locked up while trying to start, but I'm not too sure if that was a problem with the USE flags or if it's because of some other problem (Qemu not liking the idea of being run as 64-bit code maybe). I also tried downloading the pre-built binaries of Qemu for Linux, but they failed to find shared libraries on my system.
Of course I wasn't too persistent. Mostly I was doing research into EFI at the time - trying to decide if it'd be worth the trouble writing an EFI bootloader for my OS, and hoping to find some way to test the code. After installing Qemu on Windows XP (a different computer) and finding that the EFI BIOS for Qemu doesn't work "as is", I did some research on Apple machines and/or recent Intel motherboards that support EFI and decided that EFI isn't mature enough (or well supported enough) for me to worry about at the moment; and once I stopped worrying about EFI I had no reason to continue trying to get Qemu to work.
Also note that for SMP, Qemu emulates each CPU for a fixed amount of time (e.g. first CPU for 10 ms, next CPU for 10 ms, next CPU for 10 ms, etc). Because of this the chance of finding race conditions, etc is extremely small because Qemu does a few million instructions on one CPU before any other CPUs do any instructions, which makes Qemu useless for a lot of SMP testing purposes.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: More than 8 cores under bochs
Thanks for the tips, I'll look deeper into the bochs sources and maybe I can come up with a solution.Brendan wrote:I haven't done this for a while (a year or 2) and a lot has probably changed since. Normally you'd need to change a few other things, like the ""#define MAX_LOGFNS" in Bochs.h and the "#define BX_MAX_TIMERS" in pcsystem.h so that the rest of Bochs can cope with the increase in CPUs. I'm also not sure how many CPUs the current APIC code can handle - originally the APIC code used a bitfield or something that was limited to about 32 CPUs, but that was rewritten.giszo wrote:Maybe this is a really simple question but I didn't find the answer for it. So how can I tell bochs to support more than 8 cpu cores? As I see there's a BX_MAX_SMP_THREADS_SUPPORTED definition in config.h that is 8 by default. If I set the previous definition to 32 (for example) bochs simple failes to start.
Then you'd need to look into the Bochs BIOS and see what it's limitations are - mostly the code that generates the MP Specification tables and ACPI tables. I used to use my own BIOS code, so I don't know if there's problems with the Bochs BIOS code or not.
Yeah, I know that I can install n+1 versions of GCC to my gentoo but simple it would be better to have bochs running with a lot of CPUs instead of messing my system with the n+1th GCC versionBrendan wrote:For Gentoo, you can have several different versions of GCC installed at the same time and switch between them. For a quick description see this page.giszo wrote:Unfortunately I can't install qemu to my Linux (gentoo) box because it requires GCC 3.x to compile and I have 4.x only That's why I'm using bochs and looking for a solution
giszo