On Wed, Mar 22, 2023 at 11:37:10AM -0500, Andrea Bolognani wrote:
On Wed, Mar 22, 2023 at 10:36:20AM -0300, Daniel Henrique Barboza wrote:
I'm not sure if the OS overwrites the firmware when running bare metal. Usually they provide different OS images for QEMU/libvirt and bare metal systems, probably to account for these differences. Baking the firmware in the kernel like Fedora Rawhide is doing was important a few years ago when RISC-V QEMU wasn't loading the firmware by default, but now it's getting in the way.
All this said, having a look at the recently updated Fedora for RISC-V wiki, the instructions for booting with libvirt and QEMU are different. libvirt [1] is using the '-bios none' attribute with 'virt-install' + a Fedora Rawhide image, but QEMU instructions [2] doesn't use '-bios none' and it's using Fedora 37.
The libvirt instructions in that page seem to have been updated in the Fedora 30 timeframe, whereas the QEMU instructions appear to be current as of Fedora 37.
At first I don't see any particular reason of why this Fedora 37 image would work on QEMU and not on libvirt. So what t I'll do now is do some testings with libvirt and Fedora 37. If it works then this series becomes way less important.
The libvirt instructions tell you to use
--boot kernel=Fedora-Developer-Rawhide-*-fw_payload-uboot-qemu-virt-smode.elf --qemu-commandline='-bios none'
(aka -bios none -kernel foo) while the QEMU ones suggest
-bios u/usr/share/uboot/qemu-riscv64_spl/u-boot-spl.bin -device loader,file=u/usr/share/uboot/qemu-riscv64_spl/u-boot.itb,addr=0x80200000
Those are completely different approaches to booting the guest OS. The latter is much saner IMO, because it keeps the firmware under control of the host (as is the case for SeaBIOS/edk2) instead of mixing the kernel and the firmware and requiring guest-specific files to be extracted from the disk image before being able to boot.
libvirt already provides the ability to pass arbitrary paths to -bios via the <loader type='rom'> element, so making the first part work should just be a matter of pointing it to the correct path. We don't seem to have the -device loader part wired up though, so that would need to be added. Probably as an additional attribute, in the vein of nvram.template? The address would have to be specified as well.
Note that the firmware descriptor format already supports u-boot as the firmware type. So in the long run ideally you'd only need to specify
<os firmware='uboot'>
and, assuming the uboot-images-riscv64 package is installed on the host, everything should just work.
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 Was any change made to libvirt / virt-install to make this possible? - - - 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 ' 'Course you have to disable SELinux ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org