How do tohost and fromhost work?

[terabyte128]

I defined tohost and fromhostas memory locations in the linker script for a bare-metal program that I'm trying to run within spike. But I can't find anywhere how these symbols are actually used. I assumed that I could just write bytes from within my program to the location as defined by tohost and they would show up, but that doesn't seem to be the case.

How can I use these symbols to actually exchange data between spike and the host machine?

[scottj97]

Months ago I unsuccessfully tried to find the same info.

What I do understand:

Writing a 32-bit value to tohost with lsb=0 triggers a "syscall", though this mechanism doesn't seem to be used in the isa tests.

Writing a 32-bit value to tohost with lsb=1 terminates the simulation. The upper 31 bits are the exit code: 0=PASS, anything else=FAIL.

Spike detects this write to tohost address and uses it to terminate the program with either a pass or fail condition. Formerly this was in a separate riscv-fesvr ("frontend server") package.

I haven't tried to figure out fromhost, nor do any of the isa tests use this, that I can tell.

[ccelio]

fromhost, as I remember, is needed for the design-under-test to poll the host system (running the "frontend server" or fesvr) when proxying a syscall onto the fesvr. I think it basically just looks for non-zero values, but it's just whatever protocol the fesvr software feels like using.

I guess you could use fromhost to do more powerful stuff like providing inputs/loading binaries into the DUT, but generally it's a good idea to have some other mechanism for the host system to talk to the

[scottj97]

Not sure why this was closed unceremoniously. Consider this a documentation request. Since riscv-fesvr was folded in to Spike, this seems like the right repo for it.

When you say "it's just whatever protocol the fesvr software feels like using", isn't Spike that fesvr software now?

[scottj97]

I noticed in riscv-test-env/v/vm.c function do_tohost() there is code that reads from tohost and writes to fromhost, which seems backwards to me.

Also in that same file function cputchar() uses some magic value 0x0101000000000000, which doesn't seem to be explained anywhere. It also seems strange to me that it writes the char without shifting it left by 1 bit, since lsb=1 indicates test exit (as I'd explained above). Wouldn't this trigger simulation exit with an error code half of the time (any odd-valued character)?

[kathlenehurt-sifive]

I'm also trying to understand this functionality.

• Is this the only method of ending a test that Spike supports?
• Where can I decode the "magic values" written to tohost?
• Is this functionality specific to Spike? Or RISC-V?

[chaoyangnz]

Really lack of documentation. Just curious how Spike developers don’t confuse themselves. I searched everywhere on the internet, just found the readme, nothing else. The same thing applies to other knowledge like plugins. If the developers of Spike assume the users know Spike like them, please ignore my comments, otherwise it is a shame to do fundamental work without documentation.

[aswaterman]

Fine, I'll take the bait. This was an experiment that got out of the lab. The HTIF is a tether between a simulation host and target, not something that's supposed to resemble a real hardware device. It's not a RISC-V standard; it's a UC Berkeley standard. You can still use Spike without using HTIF; you just need to link in your own I/O devices instead.

Here is a brief sketch of the tohost format, excluding some stuff that I don't think is immediately relevant:

• Bits 63:56 indicate the "device".
• Bits 55:48 indicate the "command".
• Device 0 is the syscall device, which is used to emulate Unixy syscalls. It only implements command 0, which has two subfunctions (for legacy reasons, sorry for the bad design):
  • If bit 0 is clear, then bits 47:0 represent a pointer to a struct describing the syscall. The format of the syscall struct is pretty clear if you read the pk or fesvr code.
  • If bit 1 is set, then bits 47:1 represent an exit code, with a zero value indicating success and other values indicating failure.
• Device 1 is the blocking character device.
  • Command 0 reads a character
  • Command 1 writes a character from the 8 LSBs of tohost

To answer @scottj97's question, the reason the LSB being set in his example didn't exit the program is that the command was targeted towards the blocking character device, not towards the syscall device.

You might notice the 64-bit orientation. For RV32, the tohost register is zero-extended, so only device=0 and command=0 (i.e. HTIF syscalls/exit codes) are supported.

[yunusdawji]

What is the point of writing 0x0 to FFFF_F000_02 at start of riscv? It seems that its setting mux for channel select done by code in start() function of htif_emulator.h

It seems be writing to a SCR. But which is SCR is it?

[scottj97]

You can see tohost/fromhost in use in OpenSBI: htif.c

[timsifive]

You might notice the 64-bit orientation. For RV32, the tohost register is zero-extended, so only device=0 and command=0 (i.e. HTIF syscalls/exit codes) are supported.

That doesn't appear to be the case. https://github.com/riscv/riscv-isa-sim/blob/a31ac28aff73dafa41c9968452df95647cf0ae8c/fesvr/htif.cc#L219 reads a 64-bit word from memory regardless of XLEN. The problem is that on RV32 you can't do an atomic 64-bit write, so htif might only see half the word you wrote. In practice, however, it appears to work fine. I assume this is because spike executes batches of 5000 instructions at a time, so your program would have to be quite unlucky for the 2 consecutive stores to be the boundary of the 5000 instructions.

@aswaterman, would you accept a spike change that changes the htif logic to only read tohost if any of the low 32 bits set? In that case RV32 can write the high bits first, and not have to worry about this race.

[aswaterman]

That only works if we forbid messages with the lower 32 bits all zero, which isn't backwards compatible. Given the lack of HTIF device emulation support for RV32 doesn't seem like a huge problem in practice, I'm not inclined to go down that route. I'll see if I can think of a related hack that can be implemented compatibly.

[timsifive]

Maybe not compatible, but I don't know of any reason you'd want to. There are 2 devices:

1. syscall, in which case the payload either has the LSB set to exit, or it's a pointer. I imagine that pointer will always be non-zero and 4-byte aligned.
2. Character device, in which case the payload is the character to write. Writing NUL to a terminal seems rarely useful.

I am using this mechanism in the FreeRTOS demo running on spike, so it can do more or less the same thing that the FreeRTOS demo does on Qemu. Maybe proxy syscalls are a better mechanism to use?

[aswaterman]

(Well, writing NUL does happen, even if it's not useful.)

I suggest using the proxy syscalls; they are straightforward to set up and can probably provide the functionality you need.