[HN Gopher] RISC-V is getting MSIs
___________________________________________________________________
RISC-V is getting MSIs
Author : azhenley
Score : 79 points
Date : 2022-06-30 19:11 UTC (3 hours ago)
(HTM) web link (blog.stephenmarz.com)
(TXT) w3m dump (blog.stephenmarz.com)
| gavinray wrote:
| What are these MSI things useful for? (The article shows how to
| interact with it, but not what you can do with it)
|
| I know nothing about hardware
| jareklupinski wrote:
| ordinarily, you would have to dedicate a physical pin on your
| device to listen for an interrupt signal from another device.
| MSI allows you do use existing data busses, like PCI, to send
| and listen for events or matched patterns on that bus, removing
| the need for a physical pin to signal an interrupt (in some
| cases)
| gbin wrote:
| Interrupts are a way for peripherals to signal to the CPU
| something happened (packet is received, audio buffer has been
| played and I need more data, etc. the application is device
| dependent). Once a cpu receives an interrupt it jumps to a
| predetermined interrupt service routine the OS sets up to
| address the situation the peripheral signaled (usually
| ultimately in a driver). Traditionally those are carried by
| individual discreet connections to the CPU ie. a set of wires
| signaling an interrupt level. MSI is a way to virtualize this
| and have interrupts in band with the rest of the bus (Ie.
| Within the address space of the bus) instead of needing
| specific wires for each one.
| synergy20 wrote:
| Somehow I always assumed RISC-V already had MSI for its PCI-
| Express use cases, which is essential to me.
| bonzini wrote:
| Yes, the RISC-V AIA has been a standard for some months now.
| eqvinox wrote:
| That is shockingly young, like the GP I had assumed MSI
| would've been designed in when the PLIC was designed (i.e. <=
| 2019). The PLIC doc says something about "Interrupt
| Gateways", did those not make it?
| amelius wrote:
| What is the max latency of these signals?
| monocasa wrote:
| Depends on the system architecture. But a lot of complex
| systems have been message signaled internally for a very long
| time, hypertransport based systems being a prominent early
| example in the desktop/server space.
| eqvinox wrote:
| Indeed there are no interrupt pins in PCI express at all, you
| only have a choice between special "Legacy/Compatibility"
| _Assert_INTx_ message packets, or plain Memory Writes for MSI
| /MSI-X. But both are carried as in-band PCIe packets on the
| high speed lanes.
| Taniwha wrote:
| Presumably the addresses for this is configurable right? Some
| systems put DRAM at 0. If a system has a fixed address it's
| probably best to describe in the spec how to discover it in the
| device tree
| a-dub wrote:
| tangential question: if i wanted to poke around with the risc-v
| isa (like add an instruction) and then wanted to add support to
| an emulator, compiler and operating system for that instruction,
| is there an emulator, compiler and operating system that are best
| suited for this sort of isa experimentation?
| mhh__ wrote:
| Emulator is dead easy other than bit twiddling initially.
|
| The compiler aspect would depend because although compilers try
| to construct the code generator automatically (e.g. by matching
| on a tree) sometimes it requires a special case to do good
| code.
| trasz wrote:
| The CHERI team had the same problem: https://github.com/CTSRD-
| CHERI/cheribuild. You'll need something along the lines of
| "./cheribuild.py sdk-riscv64 freebsd-riscv64 disk-image-riscv64
| run-riscv64", bit of disk space, and a free couple of hours for
| it to finish building everything; at the end you'll get a login
| prompt for the guest.
| rwmj wrote:
| QEMU TCG is not that difficult to understand, and has quite
| comprehensive support for RV64 already, so you could add a new
| instruction there. As for compiler/kernel support, that's
| probably a lot more difficult, but it's hard to say what would
| be involved (eg. deep changes, or simple __asm__ statements)
| without knowing what kind of feature you'd be trying to add.
| a-dub wrote:
| what if i said risc-v isn't as important (to start), but
| rather just a dead simple isa with a dead simple emulator,
| compiler and operating system (like something that can take
| cross-compiled binaries and run them with basic input and
| output).
|
| like i'd like to experiment with novel ideas in the area, but
| ideally would like to avoid getting into the complexity of
| real compilers, operating systems and emulators until the
| ideas are looking proven...
|
| i can go looking more for stuff myself (maybe toy mips stuff
| used in schools or something) but this seems like something
| that people would do and therefore there'd be known tooling?
| lmm wrote:
| If you're asking "do simple teaching OSes/toolchains
| exist?", of course they do (Minix is the most famous one).
| If you want risc-v specifically, with a quick search I
| found xv6, which seems to have been put together for
| https://pdos.csail.mit.edu/6.S081/2021/ .
| antonly wrote:
| I built a RISC-V emulator in python focused on
| extensibility and debugability for this exact purpose. It
| should be dead simple to use with plain RISC-V Assembly
| files. It has a userspace-only mode and a minimal
| privileged mode: https://github.com/AntonLydike/riscemu
|
| Adding new instructions is as simple as adding a method to
| a class, as long as you are reading straight assembly
| files. If you want to parse ELF-files, you also have to add
| the opcodes for your command to the decoder (which is
| currently not very well documented). If you'd like to do
| that, feel free to open an issue and I'll work you through
| it.
|
| I also built a minimal kernel, which works on the emulator,
| but it doesn't support IO and is very rough around the
| edges in general.
| zx2c4 wrote:
| If you're into the open ISA idea but find the big guys a
| bit intimidating, you might have fun with OpenRISC. At
| least lately I've had a blast hacking on it. The kernel and
| QEMU implementations are very simple, and Stafford Horne is
| fun to talk with.
___________________________________________________________________
(page generated 2022-06-30 23:00 UTC)