3 ms·

Pretty cool. For RISC-V experts out there, can someone explain to me the purpose of the proxy kernel? I can't seem to wrap my head around it. Why not just run a

Pretty cool. For RISC-V experts out there, can someone explain to me the purpose of the proxy kernel? I can't seem to wrap my head around it. Why not just run a normal kernel (e.g. Linux) on top of the emulator? What advantages/disadvantages does the proxy kernel have?

monocasa 6y ago
It proxies most everything through HTIF to your host at the syscall layer so you just read(2), etc. to your host FS. It's also dead simple so you don't have to wait for it to boot really.
seldridge 6y ago
It gives you a hardware testing environment with system calls for reasonable amounts of wall clock time. If you're simulating actual hardware, e.g., a Verilog description of a RISC-V microprocessor compiled to a cycle-accurate simulation with Verilator, your simulation rate is going to be ~10KHz. You can write useful tests with the Proxy Kernel (or something like it) that run in ~1 million instructions (minutes of wall clock time) while still getting full system calls like printf. However, booting Linux is out of the question (days of wall clock time). Running bare metal is useful, too, but you don't have system calls there. If you're doing fast RISC-V virtualization, like on QEMU, or doing emulation on an FPGA, you're running at >1MHz and running a "normal kernel" like Linux is totally tractable. However, it would be foolhardy to expect to jump from hardware design to immediately booting Linux.
- fulafel 6y ago
  Nitpick: printf is is a libc call.
  - brucehoult 6y ago
    ... and that libc code (usually NewLib[nano]) formats a buffer then calls write(2), which pk provides.
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
brucehoult 6y ago
As well as very slow verilog RTL emulation, pk is also used to allow you to run standard User-mode RISC-V binaries with many kinds of systems call in them on: - software emulators - cores implemented in an FPGA - prototype chips Whatever it is, you only have to implement the CPU core, some RAM, and some sort of two-way communications channel -- whether a pipe, UART, USB Serial, ethernet or WIFI. On the other end of the communications channel you run riscv-fesvr (Front End SerVeR) pk traps systems calls, serializes the arguments, send them to fesvr. fesvr unpacks the arguments, makes the system call on the host Linux machine, serializes the results, and sends them back to the RISC-V core running in that FPGA or prototype chip or Verilator or whatever. So your test programs get to use not only printf() but also navigate the host filesystem, open files, get the time etc etc. A proper Linux Kernel on the system under test would require megabytes of RAM, various I/O devices etc. pk requires only a few kb of RAM and a communications channel.

monocasa 6y ago

It proxies most everything through HTIF to your host at the syscall layer so you just read(2), etc. to your host FS. It's also dead simple so you don't have to wait for it to boot really.

seldridge 6y ago

It gives you a hardware testing environment with system calls for reasonable amounts of wall clock time. If you're simulating actual hardware, e.g., a Verilog description of a RISC-V microprocessor compiled to a cycle-accurate simulation with Verilator, your simulation rate is going to be ~10KHz. You can write useful tests with the Proxy Kernel (or something like it) that run in ~1 million instructions (minutes of wall clock time) while still getting full system calls like printf. However, booting Linux is out of the question (days of wall clock time). Running bare metal is useful, too, but you don't have system calls there. If you're doing fast RISC-V virtualization, like on QEMU, or doing emulation on an FPGA, you're running at >1MHz and running a "normal kernel" like Linux is totally tractable. However, it would be foolhardy to expect to jump from hardware design to immediately booting Linux.

fulafel 6y ago
Nitpick: printf is is a libc call.
- brucehoult 6y ago
  ... and that libc code (usually NewLib[nano]) formats a buffer then calls write(2), which pk provides.
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]

brucehoult 6y ago

As well as very slow verilog RTL emulation, pk is also used to allow you to run standard User-mode RISC-V binaries with many kinds of systems call in them on: - software emulators - cores implemented in an FPGA - prototype chips Whatever it is, you only have to implement the CPU core, some RAM, and some sort of two-way communications channel -- whether a pipe, UART, USB Serial, ethernet or WIFI. On the other end of the communications channel you run riscv-fesvr (Front End SerVeR) pk traps systems calls, serializes the arguments, send them to fesvr. fesvr unpacks the arguments, makes the system call on the host Linux machine, serializes the results, and sends them back to the RISC-V core running in that FPGA or prototype chip or Verilator or whatever. So your test programs get to use not only printf() but also navigate the host filesystem, open files, get the time etc etc. A proper Linux Kernel on the system under test would require megabytes of RAM, various I/O devices etc. pk requires only a few kb of RAM and a communications channel.