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
