Preliminary SMP support #46
Conversation
ranvd
force-pushed
the
PR_SMP
branch
2 times, most recently
from
1e7abb0 to
1561811
Compare
There was a problem hiding this comment.
Do not submit a single pull request that involves various independent commits. Instead, this pull request should be divided into at least three distinct parts as follows.
- Modify the Linux kernel configurations to be SMP-aware, ensuring compatibility with both uniprocessor setups and implementations preceding SMP-related changes.
- Manage RISC-V harts and hart state, along with CLINT support and peripheral supports. Separate these into as many distinct git commits as feasible. Of course, the new option "smp=" should be supported by semu command line.
- Implement SMP-aware tests. The command
make SMP=n checkshould be expanded where n represents the number of harts for system emulation. Here,SMP=1should be the default configuration, but it should be possible to specifySMP=2or more for testing purposes. Instead of using a file namedminimal-quad.dts, generate 'minimal.dtsi' based on the specified SMP configurations using bash or Python scripts. Thisminimal.dtsifile will include definitions fromcpu@0tocpu@(n-1)and can be included in theminimal.dtsfile.
|
Got it. I will separate this PR into more pull requests, and leave this pull request with the actual implementation of preliminary SMP implementation . |
By changing `ie` from `uint32_t` to an array of `uint32_t`, this can simulate different interrupt enable registers for different contexts. For example, `ie[0]` simulates the interrupt enable register for the first context, which is at 0x002000 in the address map, and `ie[1]` simulates the second context with the address map at 0x002080.
Replace emu.timer with the CLINT device. This CLINT device preliminarily supports sending 4095 individual timer and software interrupts to different harts.
|
In the commit log this time, I separate the commits of PLIC, CLINT implementation and LR/SC correction. Does it needed to create new PR for each individual commit? |
You can gather them in one pull request, but you should utilize |
Sorry, I can't understand what exactly I should do. The current commit is already rebased to the latest master branch. Does "Rework the commits" mean I need to rewrite the commit message because my commit message is not clear enough to convey the idea of changes? |
The requested changes are involved in several functional and minimal commits which refer to their individual change lists. e.g.,
While the following changes should be amended into the above. e.g.,
Each commit should be fully traceable and well-understood. |
| @@ -1,5 +1,7 @@ | |||
| /dts-v1/; | |||
|
|
|||
| #include "riscv-harts.dtsi" | |||
There was a problem hiding this comment.
Add some comments such as "RISC-V hart descriptions."
common.h
Outdated
| @@ -17,6 +17,11 @@ static inline int ilog2(int x) | |||
| return 31 - __builtin_clz(x | 1); | |||
| } | |||
|
|
|||
| static inline int ffs(int x) | |||
There was a problem hiding this comment.
The ffs() function appeared in 4.3BSD. Its prototype existed previously in <string.h> before it was moved to <strings.h> for IEEE Std 1003.1-2001 ("POSIX.1") compliance.
You can include <strings.h> when needed.
riscv.h
Outdated
| }; | ||
|
|
||
| struct __vm_internel { | ||
| uint32_t hart_number; |
There was a problem hiding this comment.
Rename to n_harts for consistency.
There was a problem hiding this comment.
Is it better to rename it to hart_count? Since the variable name storing the --smp argument value is hart_count, which will be used to initialize vm.hart_number.
There was a problem hiding this comment.
Count is to enumerate one by one. Number is either total or status of anything in a series. So, we would "number" or the short form "n_" in structures. Meanwhile, we use count during initialization to emphasize the enumeration.
| @@ -386,7 +386,7 @@ static bool virtio_blk_reg_write(virtio_blk_state_t *vblk, | |||
| #undef _ | |||
| } | |||
|
|
|||
| void virtio_blk_read(vm_t *vm, | |||
| void virtio_blk_read(hart_t *vm, | |||
There was a problem hiding this comment.
For the sake of consistency, the first parameter should be exactly vm which points to the instance of virtual machine regardless of its hart configuration.
| hart->sip &= ~RV_INT_SSI_BIT; | ||
| } | ||
|
|
||
| static bool clint_reg_read(clint_state_t *clint, uint32_t addr, uint32_t *value) |
There was a problem hiding this comment.
Specify const qualifier when possible. i.e., const clint_state_t *clint.
|
I found that some implementations are not consistent with the specifications. I will update this branch afterward. |
|
Can you integrate SMP aware tests in GitHub Actions? |
|
Okay, I will integrate it by creating a new pull request afterward. |
ranvd
force-pushed
the
PR_SMP
branch
2 times, most recently
from
a29be25 to
3091d8c
Compare
In this commit, semu is able to simulate SMP architecture on Linux kernel. The original `vm_t` has been changed to `hart_t`, and now `vm_t` represents the entire virtual machine. Additionally, HSM, RFENCE, and IPI SBI extensions have been implemented with rough implementations. Also, the interrupt signal in PLIC is required to be sent to every hart. Lastly, ensure the LR/SC instructions in semu are handled properly. Before simulation, we need to enable SMP support in the Linux kernel. Please cross-compile the Linux kernel with the configuration file located at configs/linux.config After recompiling the Linux kernel with SMP support enabled, simply execute `make check SMP=n`, where n means the number of hart you want to simulate, and SMP=1 is the default setting. If you want to execute semu by yourself, the --smp argument can be used to specify the hart to simulate, and you are responsible for modifying the device tree.
Use -c for short representation of SMP option, and Leave --smp for long representation.
The mmu-type should be sv32 not rv32.
Enhance coding style by replacing "else if" with "if". Since it will return true if it fulfills the condition of the "if" statement.
|
Thank @ranvd for contributing! |
In this commit, semu is able to simulate SMP architecture running on the Linux kernel.
Before simulating SMP on semu, we need to enable SMP support in the Linux kernel. Please cross-compile the Linux kernel with the configuration file located at configs/linux.config.
After recompiling the Linux kernel with SMP support enabled, simply execute
make check SMP=1to simulate a quad-hart RISC-V CPU.