O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

The Future of Operating Systems on RISC-V

78 visualizações

Publicada em

Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/2X8uz92.

Alex Bradbury gives an overview of the status and development of RISC-V as it relates to modern operating systems, highlighting major research strands, controversies, and opportunities to get involved. Filmed at qconlondon.com.

Alex Bradbury is co-founder of lowRISC CIC, aiming to bring the benefits of open source development to the hardware industry by producing a high quality, secure, and open source SoC and associated infrastructure. He is a well-known member of the LLVM community, and is code owner and primary author of the upstream RISC-V back-end.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

The Future of Operating Systems on RISC-V

  1. 1. 4th March 2019 The future of operating systems on RISC-V Alex Bradbury asb@lowrisc.org @asbradbury
  2. 2. InfoQ.com: News & Community Site Watch the video with slide synchronization on InfoQ.com! https://www.infoq.com/presentations/ risc-v-future/ • Over 1,000,000 software developers, architects and CTOs read the site world- wide every month • 250,000 senior developers subscribe to our weekly newsletter • Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese) • Post content from our QCon conferences • 2 dedicated podcast channels: The InfoQ Podcast, with a focus on Architecture and The Engineering Culture Podcast, with a focus on building • 96 deep dives on innovative topics packed as downloadable emags and minibooks • Over 40 new content items per week
  3. 3. Purpose of QCon - to empower software development by facilitating the spread of knowledge and innovation Strategy - practitioner-driven conference designed for YOU: influencers of change and innovation in your teams - speakers and topics driving the evolution and innovation - connecting and catalyzing the influencers and innovators Highlights - attended by more than 12,000 delegates since 2007 - held in 9 cities worldwide Presented at QCon London www.qconlondon.com
  4. 4. Structure of this talk ● Introduction to RISC-V ● RISC-V status ● Selected RISC-V topics ● RISC-V and open hardware: the future ● Conclusion 2
  5. 5. Introduction to RISC-V ● RISC-V: an open standard instruction set architecture (ISA) ○ But wait, what’s an ISA? ○ Ecosystem of both open and proprietary implementations ● Allows / encourages custom extension ● Open standards, open(ish) development process, and (often) open implementations: a new model of development for the hardware industry? ● Managed by the RISC-V Foundation ● A “boring” design is a good thing in an ISA 3
  6. 6. Introduction to RISC-V: Details ● Key aim: flexibility. Scale up to HPC and down to deeply embedded MMU-less devices. ○ If standard solutions don’t work, add your own extensions ○ Flexibility can be a disadvantages. Opportunities, but also challenges ● “Base” ISAs: RV32I, RV32E, RV64I, RV128I ● Standard extensions: MAFDC ● Instruction encoding: 16-bit, 32-bit, 48-bit, ... ● Privileged vs unprivileged ISA ● Beyond the ISA 4
  7. 7. Background: FPGAs, ASICs, semiconductor economics ● FPGA: Field Programmable Gate Array ○ Pictured: Nexys A7, ~$270, Xilinx Artix-7 FPGA ○ Can run Rocket at 50MHz, boot Linux etc ● ASIC vs FPGA vs simulation ● ASIC volumes. 10s (multi-project wafer) or millions (volume run) are “easy”. Middle ground isn’t really viable ● Semiconductor licensing models 5
  8. 8. RISC-V status ● Specifications ○ User-level and privileged ISAs going through “ratification” ○ New extensions in development. Also debug, interrupt controller etc ● Compilers, libc, languages ○ gcc, LLVM/Clang, glibc, musl, Go, Rust ● Simulation platforms ○ Qemu, gem5, spike, tinyemu ● Hardware ○ SiFive “Freedom” boards, Kendryte, open-isa.org, FPGA-ready distributions (e.g. lowrisc.org) ○ Open source implementations: Rocket, PULP, ... 6
  9. 9. RISC-V status ● OS ○ FreeRTOS, Zephyr, seL4, Tock ○ HarveyOS, HelenOS ○ Linux, FreeBSD ● Bootloader ○ Coreboot, u-boot, bbl, OpenSBI ● Linux distributions ○ Debian, Fedora, Alpine, ... 7
  10. 10. Aside: Why are RISC-V pages 4KB? Check the spec For many applications, the choice of page size has a substantial performance impact. A large page size increases TLB reach and loosens the associativity constraints on virtually-indexed, physically-tagged caches. At the same time, large pages exacerbate internal fragmentation, wasting physical memory and possibly cache capacity. After much deliberation, we have settled on a conventional page size of 4 KiB for both RV32 and RV64. We expect this decision to ease the porting of low-level runtime software and device drivers. The TLB reach problem is ameliorated by transparent superpage support in modern operating systems [2]. Additionally, multi-level TLB hierarchies are quite inexpensive relative to the multi-level cache hierarchies whose address space they map. RISC-V Privileged specification 1.10 8
  11. 11. RISC-V: Selected topics 9
  12. 12. SBI: Background ● Supervisor Binary Interface (SBI) ● Privilege levels ○ M: Machine ○ S: Supervisor ○ U: User ● SBI provides an interface between the OS and Supervisor Execution Environment (SEE) ● M-mode has full system access, can be used to emulate missing functionality 10
  13. 13. SBI ● Aim: Allow a single OS binary to run on all SEE implementations ● Current interface minimal (timer, inter-processor interrupts, remote fences, console, shutdown). Proposals to extend: power management, even context switch ● Controversy: puts large amount of trust in potentially opaque binary blobs. See arguments from e.g. Ron Minnich (Coreboot) 11
  14. 14. Virtualisation ● See: “Proposal for virtualization without H mode” by Paolo Bonzini (KVM maintainer). ○ Also “RISC-V Hypervisor Extension” slides (Dec 2017, Bonzini+Hauser+Waterman) ● Rather than having H, M, S, U mode, add “virtualized supervisor” and “virtualized user” modes. Introduces “background” CSRs. ● Great example of collaborative development, benefitting from expert input 12
  15. 15. RISC-V and open hardware: the future 13
  16. 16. Ingredients for rapid hardware/software innovation ● Ideas ● Open standards ● High quality, well tested + verified open implementations ● Active development community ● Mechanism for “capturing” contributions. ○ Process for reviewing and agreeing proposals / code contributions. ○ Then shipping in future spec or hardware 14
  17. 17. Malleable hardware ● Is this a “clean slate” opportunity? ● Same old challenges (security, energy efficiency, performance). Potential for new solutions if changes are possible across ISA, microarchitecture, OS, compiler, languages, … ● More viable for some market segments than others: normal market forces still in play 15
  18. 18. ● Plan changes ● Prototype in simulator, make necessary software changes ● Modify a hardware implementation and test with FPGA / Verilator ● Publish changes and write up ● Pathway to inclusion in shipping hardware is more difficult, though multiple groups working on this ○ lowRISC is aiming for regular tapeouts so community members can see their contributions realised ○ SiFive aiming to lower barrier for new silicon ○ Whole array of other startups and organisations Idea -> prototype 16
  19. 19. ● Direct segments: optimisation for page-based virtual memory. Avoid TLB miss overhead by mapping part of a process’ virtual address space to contiguous physical memory ● Proposed originally in 2013, but evaluated using a simple analysis based on counting TLB misses ● Thanks to availability of easily modifiable hardware implementation, can perform a better analysis ● Added 50 lines of Chisel code to Rocket and 400 lines to Linux kernel ● https://carrv.github.io/2018/papers/CARRV_2018_paper_4.pdf ● Novel HDLs: does it make it easier? Example: direct segments (University of Wisconsin) 17
  20. 20. ● Tagged memory (see lowRISC tagged memory releases and HWASAN for Arm) ○ See Katie Lim’s write-up on adding Linux kernel support https://www.lowrisc.org/docs/tagged-memory-os-enablement-interns hip-2017/ ● Spectre mitigations: same story as any other ISA, but access to open source superscalar processors like BOOM for research helps a lot ● Capabilities (see CHERI) ● ... Novel security solutions 18
  21. 21. ● Small micro-controller class cores scattered across the SoC ● Using same RISC-V ISA ● Open, not hidden (a la management engine) ● Potential use cases: soft / virtualized peripherals, security policies, near data computation, debug trace processing, … ● Prototyped on lowRISC platform (using PULP core), previous GSoC student ran TCP/IP stack using Rump kernels ● See also: custom accelerators Minion cores 19
  22. 22. End goal: productive + public feedback loop between application engineers, compiler authors, micro-architects, ISA designers, ... 20
  23. 23. ● Key challenges ○ Lowering the barrier to entry ○ Increasing the incentive for participation ○ Diversity and novel solutions are great. But how to maximise code reuse and infrastructure sharing? ● Questions? ● Contact: asb@lowrisc.org ● Sound interesting? We are hiring! 7 open positions: www.lowrisc.org/jobs Conclusion 21
  24. 24. Overflow 22
  25. 25. New extensions: vector, bitmanip 23
  26. 26. Collaborative development: observations 24
  27. 27. Compliance and testing 25
  28. 28. Open FPGA toolchains 26
  29. 29. Memory model 27
  30. 30. LLVM status, development approach 28
  31. 31. Watch the video with slide synchronization on InfoQ.com! https://www.infoq.com/presentations/ risc-v-future/