Hacker News Reader

Comment by rwmj | Hacker News Reader

This is annoying because it's one of several things that stops Fedora/RISC-V from going into Fedora proper, but I'm sure it'll be sorted out.

Edit: To save anyone asking, here are the other things we're waiting on:

* Upstreaming of glibc, kernel and binutils changes.

* Availability of rackable server hardware - required so we can deploy builders in the Fedora datacenter. This is obviously the biggest blocker, and likely several years away. In the interim I'm running my own build server which is currently doing a mass rebuild, but once that is finished will pick packages from the Fedora primary architecture builders and rebuild them for riscv64 (https://fedorapeople.org/groups/risc-v/)

* Upstreaming of qemu changes (happening at the moment). Not a requirement, but nice to have.

View on HN

Upstreaming kernel changes is not going to happen until the privileged spec is frozen, and I expect that Linux developers will want RISC-V to switch from their personal configuration format to device trees. I already have a special bag of popcorn reserved for the occasion. :)

I think the argument about config-string has been won. The last post mentioning them from the team working on the privileged spec draft seemed to indicate a tactical retreat on the issue.

I actually thought the whole SBI thing might cause more popcorn when it comes to kernel upstreaming, though it has been pointed out to me that it's not conceptually that different to Xen hypercalls.

Do you have a pointer?

There are other things in the 1.9 privileged spec that are messy, but I hope that the next version has relatively large changes. That said, the development and discussion style is not very open, and that's a pity (and the justification for not releasing the source of the spec is lame at best).

https://listmaster.pepperfish.net/pipermail/lowrisc-dev-list...

This was cross-posted on RISC-V sw-dev, but Google Groups is failing to load for me right now.

Nice. I don't think the SBI is going to be a problem, it's similar to PowerPC RTAS for example.

Do they want feedback? On a very quick reading, it seems like it would be really nice if synchronous exceptions recorded the faulting opcode. x86 doesn't do this (except sort-of when using VM extensions), and it's annoying).

There is an ISA-dev mailing list where this is discussed (unfortunately a Google Group but you can subscribe using an email address):

https://groups.google.com/a/groups.riscv.org/forum/#!forum/i...

Subscribe links here: https://riscv.org/mailing-lists/

I'm not involved in the upstream project or ISA dev, but I would definitely welcome having heavyweight kernel developers like yourself contribute, because ultimately it will ensure that the hardware is practical. We're probably 1-2 years away from having lots of RISC-V devkits running Linux, and it'd be nice if they ran Linux really well.

Is having physical RISC-V hardware required, or would using an fpga-based risc-v cpu or a risc-v emulator be acceptable?

The qemu support for RISC-V is being upstreamed right now and there is also the Spike RISC-V simulator that you can use. There are various soft CPUs that can be run in FPGAs too.

Thanks for giving some specific examples of risc-v emulators. I was curious if using an fpga or emulator based solution (assuming it could fit in a rack enclosure) would be acceptable for the Fedora team, or if they wanted actual bare-metal risc-v hardware.

QEMU on modern x86 is going to give _much_ better performance than an FPGA.

Only linux-user is going to be accepted upstream until the privileged spec is finalized.

I'm looking for a performant way to run RISC-V code in the next year or so. Any idea how sophisticated the QEMU emualtor is? For instance, is it JITing to X86, or interpreting? Is there low hanging fruit there on the CPU performance side?

On a related note, is throwing money at the FPGA vendors going to change the tradeoff, or is QEMU already winning against top-end hardware?

QEMU always JITs to the host, regardless of target.

QEMU JITs the code and is very performant, much faster than any FPGAs. The two lowest hanging fruit now are:

- Multithreaded TCG would let us use multiple host cores (eg allowing parallel builds). MT-TCG is a very new feature even in QEMU.

- Adding virtio 1.0 support would allow us to use much more efficient block devices.

qemu-user exists already and avoids both these issues, however we cannot use it for final builds because of concerns over incorrect building when the kernel isn't a RISC-V kernel. For preliminary test-building it is fine, and very fast on Intel Xeon host hardware.

The FPGA based RISC-V hardware that I already have is much slower, has much less RAM and is in other ways more limited than QEMU. OTOH what's missing from QEMU is virtio support.

However none of this is relevant for Fedora builders, which must be 19" rackable server hardware. This is a non-negotiable condition from the Fedora project itself, and also quite understandable because they don't want to be managing flaky dev boards. (For those interested, we solved this for armv7 initially using Calxeda hardware, and later using aarch64 hardware running in 32 bit mode).

Is there a reason you cant use cross-builds? or qemu once it has virtio?

Cross builds aren't really a supported way to build RPMs. No other architecture supported by Fedora uses cross-compilation, so it would just be an endless stream of problems and forks.

The current autobuilder is using QEMU (without virtio, but it'd be a lot easier and faster with) running on a 16 core Xeon. https://github.com/rwmjones/fedora-riscv-autobuild

But for the Fedora official builders, it's 19" rackable RISC-V real server hardware, and that's the non-negotiable condition we've been given, which I support and understand.

It'll be a few years, but it doesn't stop people using Fedora on RISC-V right now, they just have to grab the packages from a slightly different URL: https://fedorapeople.org/groups/risc-v/

I think it might go a bit the other way around. The Government of India/IIT Madras is building their SHAKTI family RISC-V SoCs. One or two of these SoCs will be server-type hardware, and I suspect they'll want to run RHEL or similar on them once they're taped out. Of course it'll be a while before they're actually deploying them en masse.

Given that it takes a while for things to get from Fedora to RHEL, starting now seems wise.

Reply on news.ycombinator.com