ContextQMD
Back to Tock

Tock OT Notes 5/28/2020

doc/wg/opentitan/notes/2020-05-28.md

latest2.4 KB
Original Source

Tock OT Notes 5/28/2020

Present:

  • Brad Campbell (Chair), University of Virginia
  • Jon Flatley, Google
  • Silvestrs Timofejevs, lowRISC
  • Johnathan Van Why, Google
  • Alistair Francis, Western Digital
  • Alphan Ulusoy, Google
  • Phil Levis, Stanford

Updates

  • Alphan: PR #1822 ready to merge.

  • Silvestrs: I will also take a look.

  • Jon: Host-side testing functions can run single apps. Cleanup and documentation this week. Ready to share for feedback soon.

  • Brad: Working on making RISC-V compile by default on libtock-c.

MPU/PMP

  • Alistair: Want to support enhanced PMP and setup regions that the kernel cannot access.
  • Also remove the disable implementation.
  • Alphan: Related to latency improvements, namely not reconfiguring the MPU if it already configured correctly.
  • Also there is the overhead of sorting each time.
  • Brad: The challenge here is making sure the trait/interface supports a range of hardware.
  • Phil: #1822 is pretty small, looks reasonable.
  • Setting up the MPU for the kernel could be a different trait.
  • Alistair: The current trait is only designed for apps.
  • Phil: Ok to rename it.
  • Alistair: Disable semantics need to change, software cannot be sure it can always disable the MPU.
  • Phil: The comment might be unclear. Would have to look at Danilo's dissertation to see if some platforms require that disable actually disables the MPU.
  • Brad: Having a "disable" function that doesn't do anything is confusing. Sometimes you want to disable the MPU for testing.
  • Alistair: But if it is locked, can't disable.
  • Looking to move disable logic to a "clear" function, which doesn't guarantee it can actually disable anything, and then have disable just have to disable the app MPU while the kernel is running.
  • Brad: What about making the "don't reconfigure if unnecessary" part of the trait?
  • Alphan: We could just leave it as an implementation detail for now. Change the trait in the future if needed.
  • It might not be possible to do this optimization on some hardware.
  • Brad: Now would be time to change the trait, I would think.
  • Phil: It's nice that we didn't need to (really) change the trait to support this, yet we can still get the performance.
  • Brad: I'm worried this subtly will get lost, and suddenly performance will drop. But, we really don't expect too many implementations, so this is reasonable as an implementation artifact for now.