tock
Initial Support for Multicore Tock
Pull Request Overview
This pull request provides the initial support for multicore Tock and a prototype for a two-core QEMU RISC-V SMP configuration under boards/. The design adopts the share-nothing architecture of multi-kernel which allows the majority of Tock kernel code to stay untouched as the single-thread assumption does not get violated. The only place shared between kernel instances is a channel used for inter-process/kernel communication.
The current draft implements a mechanism Portal to safely share a mutable reference between kernel instances. Portal ensures at most one kernel instance can hold a valid mutable reference of the same shared object. When the move happens, the unique reference is taken and teleported to another kernel instance through the portal via the shared inter-kernel communication channel. And the channel is currently implemented as a deferred call client.
This PR also includes and is currently built upon a construct ThreadLocal that is originally implemented by @lschuermann to create a global static mut reference within the scope of a kernel instance (aka a thread).
Testing Strategy
This PR still needs to be tested. The QEMU RISC-V SMP board is currently able to move a shared counter through the portal mechanism as a proof of concept. Some implementation choices also needs to be revised to avoid potential unsoundness: for example, the interrupt handler for inter-process interrupts touches deferred calls
TODO or Help Wanted
- [x] Support for sharing a UART driver across multiple kernel instances
Documentation Updated
- [ ] Updated the relevant files in
/docs, or no updates are required.
Formatting
- [ ] Ran
make prepush.
This looks really a interesting subject, without looking in depth to this, I am a little concerned about the introduction of Mutex. One of Tock's strength was the fact that it designed lock free and thus has a very deterministic behaviour.
While I support the idea of multicore, I would love to avoid having any mutex involved.
This looks really a interesting subject, without looking in depth to this, I am a little concerned about the introduction of
Mutex. One of Tock's strength was the fact that it designed lock free and thus has a very deterministic behaviour.While I support the idea of multicore, I would love to avoid having any mutex involved.
I agree. The mutex introduced here is only for easy implementation of a inter-kernel communication channel and is not used anywhere else. The shared channel may choose to use wait-free/lock-free algorithms instead, which should be easy to replace.
Excited to see this PR up! I'm biased, but I think that this PR is a good, non-invasive step to getting initial multi-core support into Tock. Having this work on the QEMU platform means that we can iterate quickly and have people test it without being dependent on particular hardware.
Before I do a more detailed review of this, I think that it will be valuable to describe this approach in a more formal design document (RFC, TRD, ...). This way we can discuss the high-level architecture and approach disconnected from its implementation, but use this PR as a sanity check that our proposal indeed works for a real platform. I'm happy to help draft it!
