Re: [PATCH 1/4] conf: add loader type 'none'
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(a)redhat.com> wrote:
> 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.
Okay, I will start working on libvirt patches then!
> 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.
These changes wouldn't affect the qemu-riscv64_smode U-Boot build
though, would they? I don't want to discount the usefulness of other
builds, but as far as my interests are concerned that's basically the
only one I care about O:-)
We can push the current thing as-is if you want.
I understand that the process of getting packages accepted into
Fedora can be lengthy, so starting it sooner rather than later would
probably be a good idea.
> > 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).
Got it.
I don't think we're quite ready to start dealing with RISC-V CPU
features in libvirt yet. Luckily, Linux 6.4 should be right around
the corner :)
--
Andrea Bolognani / Red Hat / Virtualization