On Tue, May 23, 2023 at 08:12:17AM -0700, Andrea Bolognani 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? > > > 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. > > Loading the SPL and ITB separately would still be possible, of > course. I'm simply talking about the default experience. > > > > /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. In the interesting of being useful for once I could do this. What do you think David? > > > > 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? David mentioned these CPU flags [qemu option]: -cpu rv64,sv57=off,sv48=off However it seems this is only a temporary workaround until various language runtimes are fixed. > > 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. > > > 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. > > 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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit
