On Tue, May 23, 2023 at 06:32:07PM +0300, David Abdurachmanov wrote: > On Tue, May 23, 2023 at 6:12 PM Andrea Bolognani <abologna@xxxxxxxxxx> wrote: > > Put it another way: do you have any objections to loading > > qemu-riscv64_smode/u-boot.bin via -kernel as the default boot > > strategy for riscv64 VMs? That's what every OS other than Fedora > > already recommends doing. > > We typically use a non-release version of OpenSBI, because it has the > latest hardware support and maybe some fixes. > > For libvirt users (out-of-the box experience) that's the correct approach. > > > Loading the SPL and ITB separately would still be possible, of > > course. I'm simply talking about the default experience. > > Yeah, this default is sane. Okay, I will start working on libvirt patches then! > > Is there ongoing work to move this package to Fedora proper? In terms > > of user experience, having to download disk images from a third-party > > is mostly fine, but installing third-party RPMs on the host... Not so > > much. Having this in Fedora proper would make it a fully > > self-contained host for RISC-V TCG VMs. > > It could go as-is, but most likely will need to change. So far we > relied on a single OpenSBI FW_DYNAMIC generic image, but that changes > starting with JH7110 which has a different (i.e. non default) load > address. Thus we might need to build OpenSBI per board (or similar), > and pick the right one while building U-Boot. > > Unknown (at least for me) how things will work on TH1520 based boards too. > > One thing I am sure about is that things in the SPEC file most likely > will change once more boards from multiple vendors are supported. These changes wouldn't affect the qemu-riscv64_smode U-Boot build though, would they? I don't want to discount the usefulness of other builds, but as far as my interests are concerned that's basically the only one I care about O:-) > We can push the current thing as-is if you want. I understand that the process of getting packages accepted into Fedora can be lengthy, so starting it sooner rather than later would probably be a good idea. > > > This doesn't disable Sv48 and Sv57. I don't know the overall status, > > > but at least Golang 1.20 has a fix to support anything above Sv39. > > > > > > Not sure about other runtimes that do pointer tagging. > > > > > > See: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1991790 > > > > IIUC that's something that needs to be handled in the kernel? Or do > > we need to do something at the QEMU/libvirt/virt-install level to > > make things work? > > Basically two workarounds were created: > - Ability to control stap mode in QEMU (basically options to > enable/disable Sv39, Sv48, Sv57). > - Ability to disable that on the kernel side. > > I think the 1st one to arrive was QEMU. > > IIRC x86_64 and aarch64 are smart in the way they give virtual > addresses to user space. Which is not the case for riscv (yet). > > On the kernel side, that's part of 6.4 kernel (not released yet). Got it. I don't think we're quite ready to start dealing with RISC-V CPU features in libvirt yet. Luckily, Linux 6.4 should be right around the corner :) -- Andrea Bolognani / Red Hat / Virtualization
