On Tue, May 23, 2023 at 6:12 PM Andrea Bolognani <abologna@xxxxxxxxxx> wrote: > > On Tue, May 23, 2023 at 04:05:04PM +0300, David Abdurachmanov wrote: > > On Tue, May 23, 2023 at 3:18 PM Andrea Bolognani <abologna@xxxxxxxxxx> wrote: > > > On Tue, May 23, 2023 at 11:59:41AM +0100, Richard W.M. Jones wrote: > > > > I just came across this thread while trying to update the libvirt > > > > instructions on that page. Specifically I need to add these to the > > > > qemu command line: > > > > > > > > -bios /path/to/u-boot-spl.bin > > > > -device loader,file=/path/to/u-boot.itb,addr=0x80200000 > > > > > > Anyway, we found that the -device loader incantation above is > > > effectively equivalent to -kernel, so you can just use that instead. > > > Both -bios and -kernel are exposed by libvirt through XML elements of > > > the same names. > > > > > > Further, since QEMU loads OpenSBI as -bios by default these days, you > > > don't even need that part and can just use -kernel to point to the > > > u-boot.bin file. In this case, you should use the file that would be > > > installed as > > > > We run QEMU in a similar way as any other board. > > You mean physical boards? Yes > > > So it's U-Boot SPL, which then loads U-Boot ITB (which typically > > contains U-Boot proper, OpenSBI FW_DYNAMIC generic binary, and DTB). > > U-Boot SPL transfers control to OpenSBI and tells it how to load the > > next stage (i.e U-Boot proper). > > That sounds a bit roundabout when you consider that QEMU > automatically loads OpenSBI, and that in turn knows to jump to a > S-Mode payload such as the Linux kernel or an S-Mode build of U-Boot. > > 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. > > > > /usr/share/uboot/qemu-riscv64_smode/u-boot.bin > > > > > > by the uboot-images-riscv64 Fedora package. > > > > This is noarch package, and thus available on all arches. This package > > is only available in Fedora/RISCV Koji for now. > > You're right! I got confused because "riscv64" is in the name O:-) > > 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. We can push the current thing as-is if you want. > > > > > For the benefit of the search engine gods, this works for now: > > > > > > > > # virt-install --import --memory 8192 -n fedora-37-riscv \ > > > > --arch riscv64 --vcpus 8 \ > > > > --disk fedora-37-riscv.qcow2,format=qcow2 \ > > > > --osinfo fedora37 \ > > > > --qemu-commandline=' -bios /path/to/u-boot-spl.bin -device loader,file=/path/to/u-boot.itb,addr=0x80200000 ' > > > > 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). > > > Simply put, older disk images on newer QEMU versions might not work properly. > > I'm not too concerned about this. In the long run, it will simply not > matter. True. > > > Note that we might want to switch to EDK2 in the future for QEMU, and > > that probably will use two 32MiB pflash devices in virt machine. I > > have seen, but haven't tested QEMU + EDK2 patches. > > Yup, there's some discussion about this very topic happening right > now on the QEMU mailing list. I'm actively involved in it and it > looks like the necessary changes might be merged soon. Yup. I noticed your name on the emails. Good to know you are involved. > > I'm not sure we can count on EFI-enabled RISC-V disk images popping > up very quickly though, so I would like to improve the situation for > the disk images that are out there right now and need U-Boot to run. EFI works and some are already using it with U-Boot IIRC. Even smaller SBCs (e.g. based on StarFive JH7110) gained EDK2 port (probably not upstreamed yet). https://github.com/starfive-tech/edk2/releases So even sub-100 USD boards will get EDK2 :) Of course, that doesn't incl. ACPI. Cheers, david > > -- > Andrea Bolognani / Red Hat / Virtualization >
