On Tue, May 23, 2023 at 6:35 PM Richard W.M. Jones <rjones@xxxxxxxxxx> 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@xxxxxxxxxx> 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@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 > > > > > > > > > > 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 >
