On Mon, Apr 10, 2023 at 07:50:36PM -0300, Daniel Henrique Barboza wrote:
On 4/7/23 15:12, Andrea Bolognani wrote:
On Tue, Mar 28, 2023 at 04:46:45PM -0300, Daniel Henrique Barboza wrote: So, I talked with Canonical a few months back about this package. I'm using a F37 dev box and I had to uncompress the u-boot .deb package by hand to extract the uboot.elf file to be able to launch the guest, meaning that users that aren't using an Ubuntu host would need to go through that to boot an Ubuntu RISC-V domain. I got told that any u-boot build would work. Didn't have the opportunity to test it.
I've just tested using the u-boot.bin coming from the Ubuntu package to boot a Fedora, openSUSE and FreeBSD guests. It works fine. I might try the same with the openSUSE and FreeBSD builds of u-boot, but I don't expect the results to be any different.
I also believe that there's nothing particularly different in how RISC-V works to require a -kernel argument every time. Users don't have to do that with x86 and even ppc64 pSeries domains: you give a disk with the guest image and everything just works.
That's only partially accurate. In the case of x86_64, BIOS boot works out of the box without passing any additional parameters to QEMU, but using EFI requires a bunch more work.
Ideally we would want that for RISC-V domains as well. We'll probably need stuff done in QEMU and OpenSBI to support this use case but I believe it's worth it.
In the case of RISC-V we have additional moving parts because OpenSBI is loaded by default, but then you need u-boot on top of that. Or, further down the line, edk2. So I'm not sure we'll ever be able to get to the point where you can just pass a disk image to QEMU and expect it to boot.
Depending on how much work/how long it would take we can discuss how libvirt can ease the users pain in the meantime.
Yeah, if we can get to the point where the user only needs <os firmware='u-boot'> or <os firmware='efi'>, then that's good enough as far as I'm concerned. You already need <os firmware='efi'> for aarch64, for example, so I don't feel that would be an unreasonable burden.
Getting the Fedora version to work would be trickier. As far as I can tell, there's currently no spec-compliant way to describe a firmware that requires both -bios and -kernel to be used at the same time. Should the spec be extended? Can we get Fedora to standardize on the, at least to an outside observer, simpler approach that Ubuntu has adopted?
I believe this has to be answered by the Fedora folks, but yeah, it would be nice if Fedora could adopt the same approach that Ubuntu, Debian, OpenSuse and others are using.
Note that the Fedora RISC-V disk images can be booted just fine using a u-boot.bin file coming from Ubuntu, so this is really about Fedora as a host rather than as a guest. But yeah, we should strive to make things more seamless, which as a first step would require having u-boot.bin available in Fedora. -- Andrea Bolognani / Red Hat / Virtualization