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. And that would bring alignment with other architectures approach, which is preferrable to adding a special hack needed for riscv, because the latter is something that most mgmt apps will forget to use. Of course even better would be for riscv64 to use UEFI :-) With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
