Re: [PATCH 1/4] conf: add loader type 'none'
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