How to track HART ID when using OpenSBI / RISC-V

stillconfused · **Joined:** Fri Nov 08, 2019 5:35 pm **Posts:** 16

Hello,
I'm confused about how to store/track which HART is currently running when using OpenSBI.
The general consensus from the OpenSBI devs is to use the sscratch register[1], but I'm already using this register in my trap handler to save the HART state. I haven't been able to find any good, easy to understand example of an OS that uses OpenSBI doing this.
Does anyone have any insight into this problem, or have any good examples they can point me to of how this was solved elsewhere?
Any help would be appreciated. Thank you!

[1] https://github.com/riscv-software-src/o ... issues/233

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5146

stillconfused wrote:

The general consensus from the OpenSBI devs is to use the sscratch register[1], but I'm already using this register in my trap handler to save the HART state.

Why can't the HART ID be part of the HART state?

stillconfused · **Joined:** Fri Nov 08, 2019 5:35 pm **Posts:** 16

Octocontrabass wrote:

stillconfused wrote:

The general consensus from the OpenSBI devs is to use the sscratch register[1], but I'm already using this register in my trap handler to save the HART state.

Why can't the HART ID be part of the HART state?

Do you mean save the HART ID somewhere in the same structure I'm using to persist the HART state in my trap handler? As I understand it, without access to machine mode, the only way that I can track which HART is currently executing is to save the HART ID passed to the kernel by OpenSBI on boot. Maybe I could map some kind of per-HART structure that stores this value at the same location in virtual memory on each HART?
Do you mean something like this?
Please pardon me if I'm overlooking something obvious.

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5146

stillconfused wrote:

Do you mean save the HART ID somewhere in the same structure I'm using to persist the HART state in my trap handler?

Yes. In user mode, each HART needs to point to a different instance of that structure to prevent traps from overwriting each others' state. Since each HART is guaranteed its own structure, you can store supervisor data there without risk of another HART accidentally claiming it.

You don't need to store any supervisor data in the structure while the HART is in supervisor mode. You probably don't want to, if you have a separate instance of that structure for each task.

You also don't need to store the HART ID directly. You could store the thread pointer register and make the HART ID a thread-local variable.

stillconfused · **Joined:** Fri Nov 08, 2019 5:35 pm **Posts:** 16

Thank you for your help. I'm a little new to multi-threaded OS development, so forgive me if I'm a bit slow.
I'm getting a bit confused here about needs to be HART-specific, versus process-specific.
In my first post I made a bit of a typo. I meant to say 'I'm already using the sscratch register in my trap handler to save the process state'.
I've mitigated the issue for now by mapping a HART-specific structure into the virtual memory of each HART instance at a fixed-address.
I'm starting to think I need to go back to the drawing board and redesign how multi-threaded processing is going to work.

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5146

stillconfused wrote:

I meant to say 'I'm already using the sscratch register in my trap handler to save the process state'.

I understood what you meant anyway.

stillconfused wrote:

I've mitigated the issue for now by mapping a HART-specific structure into the virtual memory of each HART instance at a fixed-address.

What happens when your scheduler moves a process from one HART to another?

OSDev.org

How to track HART ID when using OpenSBI / RISC-V

Who is online