On Tue, May 23, 2023 at 3:18 PM Andrea Bolognani <abologna@xxxxxxxxxx> wrote:
>
> On Tue, May 23, 2023 at 11:59:41AM +0100, Richard W.M. Jones wrote:
> > 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
>
> I recommend going through the entire thread if you haven't already,
> it's full of interesting details. And it would be useful to have
> another pair of eyes go over it, just in case something was missed :)
>
> Anyway, we found that the -device loader incantation above is
> effectively equivalent to -kernel, so you can just use that instead.
> Both -bios and -kernel are exposed by libvirt through XML elements of
> the same names.
>
> Further, since QEMU loads OpenSBI as -bios by default these days, you
> don't even need that part and can just use -kernel to point to the
> u-boot.bin file. In this case, you should use the file that would be
> installed as
We run QEMU in a similar way as any other board.
So it's U-Boot SPL, which then loads U-Boot ITB (which typically
contains U-Boot proper, OpenSBI FW_DYNAMIC generic binary, and DTB).
U-Boot SPL transfers control to OpenSBI and tells it how to load the
next stage (i.e U-Boot proper).
>
> /usr/share/uboot/qemu-riscv64_smode/u-boot.bin
>
> by the uboot-images-riscv64 Fedora package.
This is noarch package, and thus available on all arches. This package
is only available in Fedora/RISCV Koji for now.
>
> > Was any change made to libvirt / virt-install to make this possible?
>
> Not yet.
>
> I would love to make booting a riscv64 VM a simple case of adding
>
> <os firmware='u-boot'/>
>
> to the domain XML, and I'm more than willing to write the necessary
> libvirt patches, but a couple of things need to happen first:
>
> * the uboot-images-riscv64 package needs to be made available on
> non-riscv64 architectures;
>
> * a JSON firmware descriptor needs to be added to said package,
> pointing to /usr/share/uboot/qemu-riscv64_smode/u-boot.bin.
>
> The first part might be tricky, as it will probably involve a
> cross-compiler, but other distributions seem to have managed to do it
> already so I don't expect Fedora to face significant roadblocks.
>
> For the second part, something along the lines of
>
> # /usr/share/qemu/firmware/30-uboot-riscv64-smode.json
> {
> "interface-types": [
> "uboot"
> ],
> "mapping": {
> "device": "kernel",
> "filename": /usr/share/uboot/qemu-riscv64_smode/u-boot.bin"
> },
> "targets": [
> {
> "architecture": "riscv64",
> "machines": [
> "virt"
> ]
> }
> ]
> }
>
> should do the trick, but note that I haven't tested it :)
>
> My only question is why the u-boot-spl.bin/u-boot.itb approach was
> chosen to be documented in the Fedora wiki? Is there something that
> I've missed and that makes it superior, or can we follow along with
> what everyone else is doing? A question for David, perhaps.
Because that's how the boards boot, and testing on QEMU is more convenient.
>
> > 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 '
This doesn't disable Sv48 and Sv57. I don't know the overall status,
but at least Golang 1.20 has a fix to support anything above Sv39.
Not sure about other runtimes that do pointer tagging.
See: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1991790
Simply put, older disk images on newer QEMU versions might not work properly.
Note that we might want to switch to EDK2 in the future for QEMU, and
that probably will use two 32MiB pflash devices in virt machine. I
have seen, but haven't tested QEMU + EDK2 patches.
Cheers,
david
>
> Based on the information above, using
>
> --boot kernel=/path/to/u-boot.bin
>
> should work...
>
> > 'Course you have to disable SELinux ...
>
> ... without requiring this :)
>
> --
> Andrea Bolognani / Red Hat / Virtualization
>
