RISC-V: Add context switching #1323

bradjc · 2019-06-11T19:37:21Z

Pull Request Overview

This pull request implements the UserlandKernelBoundary trait for RISC-V platforms.

This PR is towards tracking issue #1135.

This depends on #1318 so those commits have been included here. That PR should be merged first, and then I can update this one.

While I pulled things together for the PR, @sv2bb did much of this.

Testing Strategy

This pull request was tested by running blink and c_hello on the the arty-e21 FPGA based board.

TODO or Help Wanted

See inline comments.

Documentation Updated

Updated the relevant files in /docs, or no updates are required.

Formatting

Ran make formatall.

bradjc · 2019-06-11T19:41:07Z

arch/rv32i/src/syscall.rs

+          lw   x30, 31*4(sp)
+          lw   x31, 32*4(sp)
+
+          addi sp, sp, 33*4   // Reset kernel stack pointer


There is a lot of assembly here. At this point, however, with the kernel registers restored, we should be able to switch back to rust. The reason it is all in assembly is that the assembly needs the reference to state, but once I pass the &mut state to asm!() Rust complains whenever I try to use it again. If someone knows how to remedy this we can probably remove some of this assembly.

bradjc · 2019-06-11T19:43:17Z

boards/kernel_layout.ld

         */
        KEEP(*(.riscv.start));
+        . = ALIGN(64);
        KEEP(*(.riscv.trap));


The trap handler must be aligned to a multiple of 64 bytes. With global_asm!() this could be inserted in the assembly for the start trap function. However, using functions with asm!() I think the only place to add this is here. Does anyone know a better way?

To remove the padding on boards without this, this works:

. = DEFINED(_start_trap) ? ALIGN(64) : ALIGN(1);

Though whether it's worth the worst-case 63 bytes, I'm not sure I care as much

niklasad1 · 2019-06-12T14:21:01Z

@bradjc Maybe co-author this PR then?

Obviously setting the baud rate for UART depends on the clock speed. Make this a parameter because different boards use different settings. We probably want a more formal way to do this, but this is simple and works for now.

Co-authored-by: Samyukta Venkat <[email protected]>

bradjc · 2019-07-22T18:50:54Z

OK anyone want to take a look at this? I think we should merge quickly so we can work on #1324 more easily, and get this in for 1.4 release testing.

alevy · 2019-07-22T21:39:22Z

Maybe @DieracDelta can take a look?

@bradjc can you maybe add a link in the PR to whatever RISC-V reference is appropriate for this?

alevy · 2019-07-22T21:40:01Z

All that said, I agree we should merge this reasonably promptly, since we decided we're allowing RISC-V to move fast for now as long as it's changes that don't interfere with other platforms.

ppannuto

+1 to generally staying out of the way of self-contained RISC-V stuff for now, mostly looks good to me, a few comments but nothing I would hard-block on.

Final thought, maybe a README or something in the cores directory explaining what this beast is:

boards/arty-e21/core/sifive_coreip_E21_FPGA_Evaluation_v19_02_rc0.mcs

?

arch/rv32i/src/clic.rs

ppannuto · 2019-07-23T19:41:06Z

boards/kernel_layout.ld

         */
        KEEP(*(.riscv.start));
+        . = ALIGN(64);
        KEEP(*(.riscv.trap));


To remove the padding on boards without this, this works:

. = DEFINED(_start_trap) ? ALIGN(64) : ALIGN(1);

Though whether it's worth the worst-case 63 bytes, I'm not sure I care as much

arch/rv32i/src/clic.rs

Co-Authored-By: Niklas Adolfsson <[email protected]>

bradjc · 2019-07-30T15:35:45Z

Any other comments?

niklasad1 · 2019-07-31T21:30:31Z

arch/rv32i/src/syscall.rs

+                }
+            }
+            1 => kernel::syscall::ContextSwitchReason::Interrupted,
+            2 => kernel::syscall::ContextSwitchReason::Fault,


this seems redundant, would be caught by wildcard

niklasad1 · 2019-07-31T21:37:46Z

arch/rv32i/src/syscall.rs

+pub struct SysCall();
+
+impl SysCall {
+    pub const unsafe fn new() -> SysCall {


unnecessary unsafe, alternatively add some docs which explains why it is marked as unsafe

Agree that this is only meaningful if SysCall cannot otherwise be easily instatiated by anyone (which I believe this unsafe is meant to protect)

I think this is either a copy-and-paste artifact, or the unsafe was needed at some point during the development, and the compiler only tells you when it is necessary to add it.

niklasad1 · 2019-07-31T21:43:26Z

arch/rv32i/src/syscall.rs

+}
+
+/// Implementation of the `UserspaceKernelBoundary` for the RISC-V architecture.
+pub struct SysCall();


I would prefer pub struct SysCall; over empty unit struct but it is ok.

Actually, I think none of the above (including what’s in the code) is what we want. All of these options allow anyone to construct a SysCall since all of it’s fields (of which there are none) are public.

SysCall needs to be a singleton (I think?), and should only be insatiable through the unsafe fn new() function.

The declaration should, therefore, be:

pub struct SysCall( () ); // Can elide spaces

Which would result in an error if someone outside of this module tries to create one. Unlike:

pub struct SysCall(pub ());

Which can be instantiated by anyone.

Right, if it needs to be a singleton then it makes sense.

I think I updated this correctly, let me know if not.

boards/arty-e21/src/io.rs

arch/rv32i/src/syscall.rs

niklasad1 · 2019-07-31T22:03:38Z

chips/arty_e21/src/chip.rs

+}
+
+impl ArtyExx {
+    pub unsafe fn new() -> ArtyExx {


unsafe block could be removed if you agree with my comment in SysCall impl

niklasad1

This is cool, LGTM overall but I haven't read the assembly stuff...

Added some inline comments mainly rust style stuff

alevy · 2019-08-01T15:00:05Z

arch/rv32i/src/syscall.rs

+pub struct SysCall(());
+
+impl SysCall {
+    pub const fn new() -> SysCall {


Is it, or is it not safe to have multiple instances of SysCall? If it is, than this is fine, but the definition of SysCall doesn't need to have any extra parens or unit types, just a plain pub struct SysCall; is good enough.

If it does, then this has to be marked unsafe.

This is a discrepancy we have in the cortex-m variants as well (where this was likely copied from). Let's decide here and fix in the cortex-m in a different PR.

It certainly doesn't make a lot of sense to have multiple SysCall objects, but I'm not sure if it is strictly safe or not. Since everything is handled on the stack it might be safe.

We typically think of it as potentially unsafe when we have might end up with two instances that use the same set of hardware registers, so that they are not actually isolated instances...

I think in this particular case, I think switch_to_process is what should motivate us to ensure SysCall is a singleton and keep new unsafe: It's operating on a shared hardware variables, such as mscratch, mepc etc...

bradjc · 2019-08-02T17:16:46Z

bors r+

@sv2bb

1323: RISC-V: Add context switching r=bradjc a=bradjc ### Pull Request Overview This pull request implements the `UserlandKernelBoundary` trait for RISC-V platforms. This PR is towards tracking issue #1135. This depends on #1318 so those commits have been included here. That PR should be merged first, and then I can update this one. While I pulled things together for the PR, @sv2bb did much of this. ### Testing Strategy This pull request was tested by running blink and c_hello on the the arty-e21 FPGA based board. ### TODO or Help Wanted See inline comments. ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make formatall`. Co-authored-by: Brad Campbell <[email protected]>

bors · 2019-08-02T17:25:23Z

Build succeeded

continuous-integration/travis-ci/push

bradjc commented Jun 11, 2019

View reviewed changes

bradjc mentioned this pull request Jun 11, 2019

Tracking: Support RISC-V #1135

Closed

20 tasks

bradjc and others added 4 commits July 22, 2019 14:08

sifive: add clock speed as argument to uart

df2dd4d

Obviously setting the baud rate for UART depends on the clock speed. Make this a parameter because different boards use different settings. We probably want a more formal way to do this, but this is simple and works for now.

risc-v: add e21 core and context switching

fd0ef2d

Co-authored-by: Samyukta Venkat <[email protected]>

doc: add risc-v context switch details

616f9bb

doc: no longer cortex-m only!

5414ac4

bradjc force-pushed the riscv-pr branch from cc36f23 to 5414ac4 Compare July 22, 2019 18:39

ppannuto reviewed Jul 23, 2019

View reviewed changes

niklasad1 reviewed Jul 23, 2019

View reviewed changes