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

[Andrea Bolognani]

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