<alexsaezm>
I never played with RISCV at all but I'm curious to know how good Go works on it so I was thinking in running some builds here and there while I work
davidlt has joined #fedora-riscv
<davidlt[m]>
Yes, this one. StarFive Tech. VisionFive V2.
<davidlt[m]>
Uh, ah, maybe you are one of Go package maintainer on Fedora?
<davidlt[m]>
alexsaezm: I am looking for someone to finish up and polish everything for Golang ecosystem on Fedora/RISCV.
<davidlt[m]>
IRC channels seems quite silent.
<alexsaezm>
I answered you in the go sig when you wrote :)
<davidlt[m]>
Huh, I don't see it.
<alexsaezm>
odd
<davidlt[m]>
Not really. I might have disconnected from IRC at that time. I only got response from gotmax23 IIRC.
<alexsaezm>
and yes, I'm one of golang maintainers in Fedora and RHEL
<davidlt[m]>
I also pinged Robert-André Mauchin, but so far didn't get any response.
<davidlt[m]>
Well, in that case I need you! 😸
<alexsaezm>
Can't really commit any time to this but I'm interested in RISCV from the 0 experience :)
<davidlt[m]>
Okay, we need you 😼
<alexsaezm>
But I'll do my best :P
<davidlt[m]>
Well, basically everything works. Most of the true problems were solved back in aarch64 days.
<davidlt[m]>
And we have been building Fedora/RISCV since 2016.
<davidlt[m]>
We typically fall short of about ~2000 packages from upstream Fedora Koji instance. There is always something like 600-1000 that in general no longer build, and some that never actually built.
<alexsaezm>
Correct me if I'm wrong (still didn't read two books I have open on my desk about RISCV lol) but... is there an standard RISCV target architecture? or each system is slightly different?
<davidlt[m]>
But we have a few unfinished things in Java and Golang side.
<alexsaezm>
s/an/a/
<alexsaezm>
do you have a list?
<davidlt[m]>
So what we support right now is RV64GC ISA + LP64D ABI.
<davidlt[m]>
Which is basically just ratified RVA20 RISCV Profile.
<alexsaezm>
thanks, I was gonna ask for something like that :D
<davidlt[m]>
There are about ~130 ratified extensions, and another ~50 extensions incoming (ISA stuff).
<davidlt[m]>
There are a bunch of non-ISA specification also incoming.
<davidlt[m]>
There will be top-level spec, called Platforms.
<davidlt[m]>
That means at some point we will target a Platform.
<davidlt[m]>
That incl. non-ISA bits, like how we talk to the firmware, runtime, bootloaders, IOMMUs, etc.
<davidlt[m]>
How PCIe stuff works, and various other things.
<davidlt[m]>
RVA23 is new "major" profile. RVA22 is a "minor" one, kinda a stop gap.
<davidlt[m]>
Most vendors (especially going for the high-perf market) are most likely shooting for RVA23. That's way it's a major profile instead of a minor one.
<alexsaezm>
oh I see Jeff Law in it... this is going to be fun
<davidlt[m]>
I am still working on Fedora 38 image, so you can directly upgrade to Koji repos to match Fedora 38.
<davidlt[m]>
Yeah.
<davidlt[m]>
So the problem is that future Fedora RISCV is not Fedora from today.
<davidlt[m]>
That's mostly because Platforms will most likely require RVA23.
<alexsaezm>
Understood
<davidlt[m]>
No enterprise system will be working on RVA20 (expect if you are Alibaba T-HEAD).
<davidlt[m]>
The problem is that majority of users (even developers) will not be able to afford RVA23 hardware.
<davidlt[m]>
All our userbase (incl. developers) will be on RVA20 for some years to come.
<alexsaezm>
right, because it's like a "server" target based
<alexsaezm>
Ok, so you want to target RVA20 so more people can use it on daily basics
<davidlt[m]>
Yeah, it's like early AArch64 days. Getting APM Mustang was really hard, you had to be in a line basically. It was 3000 USD initially too.
<alexsaezm>
RVA23 will be compatible with RV20?
<alexsaezm>
RVA20 sorry
<davidlt[m]>
My suggestion was that "riscv64" continues to be "rva20", and we introduce "rva23" as a separate arch. Different repositories.
<davidlt[m]>
Yeah, you can run RVA20 binaries on RVA23 hardware.
<davidlt[m]>
But it's not x86_64 v2/3/4 situation.
<davidlt[m]>
You will loose a lot more performance.
<davidlt[m]>
Significantly more.
<davidlt[m]>
x86_64 baseline is very old, but it also is very modern compared to "rv64gc".
<alexsaezm>
So running a RVA20 binary on a RVA23 is slower?
<davidlt[m]>
So RVA23 is just bring a bunch of missing ISA (and non-ISA) features.
<davidlt[m]>
Yeah.
<davidlt[m]>
You are wasting that expensive silicon basically.
<alexsaezm>
oh ok, because you are not using the whole thing
<davidlt[m]>
Yeah.
<alexsaezm>
got it, I thought it was some kind of weird situation where it under performs in comparison to a proper RVA20
<davidlt[m]>
No, even just adding bit manip extensions already significantly improves performance.
<davidlt[m]>
The existing (and few future RVA profile) are all about closing the gaps with x86_64 and aarch64 land.
<alexsaezm>
honestly, didn't know RISCV was that on top of their stuff :D this sounds great
<davidlt[m]>
We have bare bones with RV64GC / RVA20 Profile, but we don't have all the basics in for modern compute.
<davidlt[m]>
There is significant modentum now, large companies, HPC/Enterprise grade silicon, tons of money, etc.
<davidlt[m]>
It's a time we can now settle on some standards.
<alexsaezm>
Yeah, I started to get interested recently since FOSDEM, had really interesting conversations with some folks about it
<alexsaezm>
a lot of people around me are starting to talk :D
<davidlt[m]>
Yeah, I have been listening to folks. It seems most of the questions are still the same ones from 2016, 17, 18 era.
<davidlt[m]>
It feels we need to "go back" and do more presentation/talking about it.
<alexsaezm>
that would be nice :D
<alexsaezm>
so, to the issue
<alexsaezm>
Go
<alexsaezm>
which packages are failing
<alexsaezm>
what can I start doing? :)
<alexsaezm>
please tell me the compiler works ::D
<davidlt[m]>
It all works, but there is probable <10% of packages that are still missing.
<davidlt[m]>
That's because of bootstrap nightmare (cyclic dependencies).
<alexsaezm>
Some packages are not multi arch even if Go can (Delve being the first one coming to mind)
<davidlt[m]>
It would cost me significant amount of time to just focus on this.
<davidlt[m]>
That's fine. Not every package builds for all arches.
<alexsaezm>
I guess I know which next arch I'm gonna try to port Delve to when I'm done with my current PR... sigh
<alexsaezm>
golang-x-tools, this is going to be fun
<davidlt[m]>
gopls (language server) depends on golang-honnef-tools and golang-x-vuln. Removing gopls solves that problems, but there are more cyclic deps.
<davidlt[m]>
The next dependency between x-tools and x-text is bit more complicated as that goes into internals IIRC.
<davidlt[m]>
Basically in a bootstrap scenario the goal is to cut cyclinc deps, remove features, hack the code until it builds, and slowly bring it up towards a full featured build.
<davidlt[m]>
Like removing gopls solves some problem, and gopls isn't used as a dependency in other packages.
<davidlt[m]>
But I never finished the whole thing.
<davidlt[m]>
Thus I need someone to figure out how to do it (and actually do it).
<davidlt[m]>
and make sure everything else in Golang related just works. What doesn't work create tickets for porting, and ExcludeArch (or/and disable specific features).
<alexsaezm>
it sounds exiting and like a lot of work :) so, two things, first I need to ask my manager if I can put some cycles on it on weekly basis, second, I need to know how to start playing with this :D
<davidlt[m]>
I think we don't even have podman, which is kinda bad.
<alexsaezm>
if I don't get it the permission, it's going to be just my best effort :D so I'm in in any case
<davidlt[m]>
rwmjones: could you somehow help with above ^^
<alexsaezm>
how can I build "a lab"? qemu? get a board?
<davidlt[m]>
The boards we support (and use in the build farm) you cannot get. Those are not sold for the last 1+ year now.
<davidlt[m]>
We will support VisionFive V2 relateively soonish.
<davidlt[m]>
QEMU/libvirt is what works.
<davidlt[m]>
See the link I posted on setup.
<davidlt[m]>
There will be something better as I am preparing Fedora 38.
<alexsaezm>
got it, I'll try to follow those instructions and get a qemu that works
<alexsaezm>
hope it doesn't give me a hard time like aarch64 or ppc64le qemu...
<davidlt[m]>
There is a small problem that is not documented. You most likely will want to use QEMU 8.0.0, and set it to use Sv39.
<alexsaezm>
that information goes to my trello board like right now :D
<davidlt[m]>
Basically: Support for setting the virtual address width (ie, sv39/sv48/sv57) on the command line.
<davidlt[m]>
QEMU defaults to Sv57 or Sv48, but things like V8/Node, Golang, etc. aren't ready to support anything above Sv39.
<davidlt[m]>
Basically they hackish way to handle pointer tagging gets broken.
<davidlt[m]>
Also kernel v6.3 should have a command line option too.
<davidlt[m]>
If you want to use Golang you need to restrict your system to Sv39.
<davidlt[m]>
All the existing hardware is only Sv39.
<davidlt[m]>
There are some that are coming out with Sv48 now (not yet available to buy).
<davidlt[m]>
Thus on the existing (and near future harware) you are not gonna see that problem.
<davidlt[m]>
But QEMU default virt machine enables way more extensions and other features.
<alexsaezm>
Understood. I'll build a lab :) I'll bother you soon :) (for now, I need to work on other stuff, but I'll try to have time for this)
<alexsaezm>
thank you very much for all the explanations, they were WAY better than me looking for info out there
jcajka has joined #fedora-riscv
<davidlt[m]>
I am here most of the time to answer the questions.
<davidlt[m]>
Time to unpack a brand new NVMe and try to prep initial Fedora 38 image.
<davidlt[m]>
It still uses old kernel, OpenSBI, U-Boot (because I know they work).
<davidlt[m]>
If all looks goods on the userspace it I will handle those next.
<davidlt[m]>
I wonder what will happen sooner. Starship flying or Fedora 38 booting.
davidlt has quit [Remote host closed the connection]
<rwmjones>
morning davidlt[m]
<davidlt[m]>
morning
<rwmjones>
quite a lot of text there, any tl;dr?
<davidlt[m]>
Not really, general information about RISCV, RV64GC, Profiles, etc.
<rwmjones>
ok, I did read a bit about that earlier
<davidlt[m]>
alexsaezm: is interested in helping out on Golang side, and I suggested to talk to you (as he is from Red Hat too).
<rwmjones>
btw we are trying to get funding for me to go to devconf.cz
<rwmjones>
looks about 80% likely
<davidlt[m]>
Nice
<davidlt[m]>
rwmjones: there is also a discussion on Fedora mailing-list, you might want look at it and join in
<cwt[m]>
I just upgrade my PC to F38
<rwmjones>
ok
<rwmjones>
on fedora-devel?
<davidlt[m]>
Yeah, it also touched topics you will not like :)
<cwt[m]>
clang-16 doesn't like -mcpu option anymore, I have to change it to -mtune
* rwmjones
wonders what "vendor lock" is
<cwt[m]>
> clang-16: warning: argument unused during compilation: '-mcpu=tremont'
<davidlt[m]>
So RPM packages have Vendor: entry
<davidlt[m]>
eg. Fedora Project
<davidlt[m]>
DNF supports "vendor lock". So if you have multiple repositories, multiple ABC.rpm in those with different vendor in the header you can lock it.
<cwt[m]>
-mcpu=native also not working, but -mtune=native works
<davidlt[m]>
Basically if you flip vendor lock, DNF will not replace the package with some other vendor pacakge.
<rwmjones>
ok, is it relevant to risc-v in some way? we seem to only have one repository at the moment
<davidlt[m]>
DNF: allow_vendor_change
<davidlt[m]>
> If disabled dnf will stick to vendor when upgrading or downgrading rpms. Default is True
<davidlt[m]>
It's relevant for vendor repositories (i.e. 3rd party ones).
<davidlt[m]>
For example, SiFive, Ventana, Rivos, etc. might want to ship their own toolchain or something like that.
<davidlt[m]>
Or some optimized packages.
<davidlt[m]>
All those GCC RPMs would have a different vendor.
<davidlt[m]>
If you have allow_vendor_change == False when you can install a vendor package, change configuration and DNF will not consider a newer NVR from a different repo.
<rwmjones>
wouldn't we want people to be able to use those?
<davidlt[m]>
Basically saying that: I want this package from this specific vendor.
<cwt[m]>
I would like to have that option, on some packages I tried, if rebuilt with a specific CFLAGS for the running CPU, the performance will be boosted by 10% - 20%.
<davidlt[m]>
Nice.
<davidlt[m]>
It already exist, it's just default is True, not False.
<davidlt[m]>
I think, Conan Kudo , would also like that go be False by default.
<Eighth_Doctor>
yes
<davidlt[m]>
Oh man, shouldn't you be sleeping?
<Eighth_Doctor>
someone propose it for F39
<rwmjones>
Eighth_Doctor: you gonna work on RISC-V now you're at Red Hat ..?
<Eighth_Doctor>
rwmjones: lol, I'm in _sales_, what do you think?
<davidlt[m]>
:D
<davidlt[m]>
So vendor lock is one discussion, not the primary one.
<davidlt[m]>
RVA20/22/23/.. and riscv64 is the main thing here.
<rwmjones>
:-(
<Eighth_Doctor>
the DNF team wants someone to propose a change to switch the behavior
<Eighth_Doctor>
I discussed with them last year about having the behavior flipped for RHEL, because there's tons of good reasons for it
<Eighth_Doctor>
but they said they'd only consider it if it's flipped in Fedora first
<davidlt[m]>
If there are tons of good reason, why not write what change proposal?
<davidlt[m]>
Because I don't know all of them (most likely).
<rwmjones>
I'm still unclear what this flag does
<rwmjones>
does it stop you from installing RPMs from the other vendor repo?
<Eighth_Doctor>
it tells libsolv to check upgrade candidates to see if they have a matching "Vendor" tag
<Eighth_Doctor>
if they don't, by default it won't let you upgrade to it unless you specifically force it
<rwmjones>
also is the flag actually 'allow_vendor_change' ?
<davidlt[m]>
Installed packages are lock to a particular vendor (based on RPM headers).
<davidlt[m]>
Yes
<davidlt[m]>
It's in DNF documentation.
<rwmjones>
so that's set to True for me (the default)
<Eighth_Doctor>
yes
<davidlt[m]>
Yes
<rwmjones>
which seems bad, maybe, it might be better for it to be False
<Eighth_Doctor>
yup
<rwmjones>
unless there are "bad vendors" out there
<davidlt[m]>
Yeah, by default False is a safer option in my opinion.
<rwmjones>
seems like True is going to be a cause of confusion
<Eighth_Doctor>
whether they're good or bad doesn't matter, the idea is that whatever the user initially chose is locked into
<rwmjones>
it seems to violate the principal of least surprise
<Eighth_Doctor>
two places already switch it to False: Fedora Asahi and CentOS Hyperscale
<davidlt[m]>
Well, it's probably too late to discuss the flag name as it's in DNF since 2021 :)
<Eighth_Doctor>
the flag name came from zypper, so...
<Eighth_Doctor>
which got it from libsolv
<Eighth_Doctor>
the name of the flag is very, very, very old
<davidlt[m]>
Yeah, OpenSUSE folks support locking/pinning vendor.
<rwmjones>
sorry, got a meeting, biab, I'll read the rest of that thread
masami has joined #fedora-riscv
masami has quit [Quit: Leaving]
somlo_ has joined #fedora-riscv
somlo has quit [Read error: Connection reset by peer]
jcajka has quit [Quit: Leaving]
jednorozec has quit [Ping timeout: 276 seconds]
somlo_ has quit [Read error: Connection reset by peer]