Starting a riscv64 VM from an ArchLinux x86_64 host

[Andrej Podzimek]

Hi Fedora developers!

I'm trying to start a Fedora riscv64 VM on an ArchLinux x86_64 host based on this wiki
page: https://fedoraproject.org/wiki/Architectures/RISC-V/Installing I have a reasonably
recent qemu and virt-manager:

```
qemu 6.0.0-3
qemu-arch-extra 6.0.0-3
libvirt 1:7.3.0-1
virt-manager 3.2.0-1
```

All virt-builder steps work perfectly fine and produce an image.

However, I cannot start an instance. I tried the image prepared with virt-builder, the
manually downloaded image, the nightly image, direct kernel loading (configured in libvirt
/ virt-manager), but none of that worked.

For the nightly instances in particular, the wiki says one should extract
"firmware" from /opensbi/... in the image. However, there is _no_ such directory
in the image (and also no file called .elf). This information may be outdated.

When using the downloaded .elf file (as described in the "Download using
virt-builder" section), I get this from qemu:

```
qemu-system-riscv64: Some ROM regions are overlapping
These ROM regions might have been loaded by direct user request or by default.
They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into
guest memory.
Check whether you intended to load all this guest code, and whether it has been built to
load to the correct addresses.

The following two regions overlap (in the memory address space):
   /usr/bin/../share/qemu/opensbi-riscv64-generic-fw_dynamic.bin (addresses
0x0000000080000000 - 0x0000000080012558)
  
VirtualMachineMedia/Fedora-Developer-Rawhide-20200108.n.0-fw_payload-uboot-qemu-virt-smode.elf
ELF program header segment 0 (addresses 0x0000000080000000 - 0x000000008000d0e0)
```

The qemu command line was:

```
qemu-system-riscv64 \
     -nographic \
     -machine virt \
     -smp 8 \
     -m 32G \
     -kernel
VirtualMachineMedia/Fedora-Developer-Rawhide-20200108.n.0-fw_payload-uboot-qemu-virt-smode.elf
\
     -object rng-random,filename=/dev/urandom,id=rng0 \
     -device virtio-rng-device,rng=rng0 \
     -device virtio-blk-device,drive=hd0\
     -drive
file=VirtualMachineMedia/Fedora-Developer-Rawhide-20210421.n.0-sda.raw,format=raw,id=hd0
\
     -device virtio-net-device,netdev=usernet \
     -netdev user,id=usernet,hostfwd=tcp::10000-:22
```

Idea No. 1: Drop the "-kernel ..." argument. In that case I get an OpenSBI
splash that looks like this: https://pastebin.com/5QKJqkRg Sadly, the VM is frozen and
nothing else happens. There is no network communication either.

It looks like this^^^ configuration might start something, but fails to load a kernel
properly (or the like). The nightly image appears to contain multiple bootloaders, but the
wiki doesn't say how to run them.

Idea No. 2: Delete /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.bin to see if the
conflict goes away. (For the record, the file is owned by qemu-arch-extra.) Well, qemu
then says 'qemu-system-riscv64: Unable to load the RISC-V firmware
"opensbi-riscv64-generic-fw_dynamic.bin"'.

Idea No. 3: Extract the kernel (vmlinuz-5.10.6-200.0.riscv64.fc33.riscv64) and initramdisk
(initramfs-5.10.6-200.0.riscv64.fc33.riscv64.img) from the nightly image and load them
"directly" (using virt-manager) like this: https://pastebin.com/36RVR75r

This^^^ failed the same way as all virt-manager experiments (with nightly / manually
downloaded / built with virt-builder) images: A black console with a blinking cursor and
nothing happens. No activity on the virtual bridge either.

Interestingly, each time qemu starts and freezes, host CPU utilization is about 200%
(i.e., 2 cores worth of load, not 1 core, not 8 cores etc.). (The host machine is a Ryzen
3950X with 32 CPUs altogether and 128 GB RAM.)

What am I doing wrong (apart from not using Fedora as a host)?
Why am I getting a weird conflict with a system built-in OpenSBI? Could the built-in
firmware be incompatible with the Fedora image?
Are there any up-to-date instructions on how to get the recent nightly images (without the
/opensbi directory) working?
How can I debug why qemu / OpenSBI freezes? Does OpenSBI need a bit of configuration to
boot the image?

I'll retry this on a Fedora VM if need be, but would also like to understand what the
issue is on Arch. Also, I wanted to double-check that the riscv64 port actually works on
current systems...

Just about any hint would help a lot. :-)

Cheers!
Andrej