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