[PATCH 1/4] conf: add loader type 'none'

Tue May 23 15:46:59 UTC 2023

On Tue, May 23, 2023 at 6:35 PM Richard W.M. Jones <rjones at redhat.com> wrote:
>
> On Tue, May 23, 2023 at 06:32:07PM +0300, David Abdurachmanov wrote:
> > On Tue, May 23, 2023 at 6:12 PM Andrea Bolognani <abologna at redhat.com> wrote:
> > >
> > > On Tue, May 23, 2023 at 04:05:04PM +0300, David Abdurachmanov wrote:
> > > > On Tue, May 23, 2023 at 3:18 PM Andrea Bolognani <abologna at redhat.com> 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
> > > > >
> > > > > 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.
> > >
> > > You mean physical boards?
> >
> > Yes
> >
> > >
> > > > 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).
> > >
> > > That sounds a bit roundabout when you consider that QEMU
> > > automatically loads OpenSBI, and that in turn knows to jump to a
> > > S-Mode payload such as the Linux kernel or an S-Mode build of U-Boot.
> > >
> > > Put it another way: do you have any objections to loading
> > > qemu-riscv64_smode/u-boot.bin via -kernel as the default boot
> > > strategy for riscv64 VMs? That's what every OS other than Fedora
> > > already recommends doing.
> >
> > We typically use a non-release version of OpenSBI, because it has the
> > latest hardware support and maybe some fixes.
> >
> > For libvirt users (out-of-the box experience) that's the correct approach.
> >
> > >
> > > Loading the SPL and ITB separately would still be possible, of
> > > course. I'm simply talking about the default experience.
> >
> > Yeah, this default is sane.
> >
> > >
> > > > >   /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.
> > >
> > > You're right! I got confused because "riscv64" is in the name O:-)
> > >
> > > Is there ongoing work to move this package to Fedora proper? In terms
> > > of user experience, having to download disk images from a third-party
> > > is mostly fine, but installing third-party RPMs on the host... Not so
> > > much. Having this in Fedora proper would make it a fully
> > > self-contained host for RISC-V TCG VMs.
> >
> > It could go as-is, but most likely will need to change. So far we
> > relied on a single OpenSBI FW_DYNAMIC generic image, but that changes
> > starting with JH7110 which has a different (i.e. non default) load
> > address. Thus we might need to build OpenSBI per board (or similar),
> > and pick the right one while building U-Boot.
> >
> > Unknown (at least for me) how things will work on TH1520 based boards too.
> >
> > One thing I am sure about is that things in the SPEC file most likely
> > will change once more boards from multiple vendors are supported.
> >
> > We can push the current thing as-is if you want.
>
> The "hump" here is getting it through the Fedora approval process.
> Once in we can add additional features very easily.
>
> If you want me to do this let me know, I can start right away (still
> fiddling around with benchmarking that qemu instance so I'm not fully
> occupied right now).

There are a few items I posted today on Fedora RISC-V Matrix/IRC
channel. There is plenty of work ;)

Sure.

Technically there are two opensbi packages we have in Fedora/RISCV:
"opensbi" (stable, we never use it), and "opensbi-unstable" (basically
OpenSBI master branch, which we always use [hardware support]).

So look at those to figure out the best action plan.

Technically QEMU ships with its own OpenSBI. Did we ever get that
sorted out in Fedora too? I recall you working on it a year or more
ago.

david

> Rich.
>
> > >
> > > > > > 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
> > >
> > > IIUC that's something that needs to be handled in the kernel? Or do
> > > we need to do something at the QEMU/libvirt/virt-install level to
> > > make things work?
> >
> > Basically two workarounds were created:
> > - Ability to control stap mode in QEMU (basically options to
> > enable/disable Sv39, Sv48, Sv57).
> > - Ability to disable that on the kernel side.
> >
> > I think the 1st one to arrive was QEMU.
> >
> > IIRC x86_64 and aarch64 are smart in the way they give virtual
> > addresses to user space. Which is not the case for riscv (yet).
> >
> > On the kernel side, that's part of 6.4 kernel (not released yet).
> >
> > >
> > > > Simply put, older disk images on newer QEMU versions might not work properly.
> > >
> > > I'm not too concerned about this. In the long run, it will simply not
> > > matter.
> >
> > True.
> >
> > >
> > > > 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.
> > >
> > > Yup, there's some discussion about this very topic happening right
> > > now on the QEMU mailing list. I'm actively involved in it and it
> > > looks like the necessary changes might be merged soon.
> >
> > Yup. I noticed your name on the emails. Good to know you are involved.
> >
> > >
> > > I'm not sure we can count on EFI-enabled RISC-V disk images popping
> > > up very quickly though, so I would like to improve the situation for
> > > the disk images that are out there right now and need U-Boot to run.
> >
> > EFI works and some are already using it with U-Boot IIRC.
> > Even smaller SBCs (e.g. based on StarFive JH7110) gained EDK2 port
> > (probably not upstreamed yet).
> >
> > https://github.com/starfive-tech/edk2/releases
> >
> > So even sub-100 USD boards will get EDK2 :) Of course, that doesn't incl. ACPI.
> >
> > Cheers,
> > david
> >
> > >
> > > --
> > > Andrea Bolognani / Red Hat / Virtualization
> > >
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
>