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. > > > 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? > 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. -- Andrea Bolognani / Red Hat / Virtualization
