Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maximum core count greater than 8? #49

Open
muwyse opened this issue Sep 23, 2021 · 1 comment
Open

Maximum core count greater than 8? #49

muwyse opened this issue Sep 23, 2021 · 1 comment

Comments

@muwyse
Copy link

muwyse commented Sep 23, 2021

Background

I am working to emulate/simulate RISC-V systems (using multiple tools) with more than 8 cores and booting SMP Linux with the OpenSBI bootloader. I currently have a setup that works with both Dromajo and QEMU (v6.1.0) to boot OpenSBI v0.9 with Linux Kernel v5.9 and a simple Buildroot/Busybox filesystem. This system successfully boots in Dromajo with up to 8 cores, but fails at higher core counts due to the hard-coded core count limit of 8 in Dromajo (

#define MAX_CPUS 8
).

I attempted to modify the source code and increase this limit, say to 32, but running with anything more than 8 cores results in either an error (e.g, with 9 cores: riscv_cpu_read_memory: invalid physical address 0x0000000000011000) or a segmentation fault of Dromajo itself. One potential conclusion is that the Dromajo generated device tree is invalid for core counts > 8 and it isn't allocating a large enough memory range for some device.

Questions

What is the motivation for limiting Dromajo to simulating 8 cores maximum and what are the constraints or requirements for increasing the maximum core count?

Are there any short-term workarounds for running with > 8 cores (e.g., if this is indeed a device tree issue and it is possible to provide a custom device tree)?

Branch/Commit

master at 3675ba0

Misc

Note that unmodified QEMU v6.1.0 has a similar hard-coded core limit for the riscv64-virt machine, but increasing this limit and rebuilding QEMU seems to cause no problems.

@et-tommythorn
Copy link
Collaborator

There is not particular motivation, it was just a limit set somewhere and it would be interesting to raise it in a way that doesn't penalize lower, or even single, core simulations.

Regarding the device tree, it doesn't seem that it should be very hard to expand it, but there's a bigger question of whether Dromajo really should be producing this rather than consuming it (or both potentially).

TL;DR: I'd be very interested in pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants