Re: [PATCH 1/4] conf: add loader type 'none'
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