sorear[m] changed the topic of #riscv to: Matrix users: #riscv:libera.chat will be ending operation NET Jul 25; please test #riscv:catircservices.org as a replacement | RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
GenTooMan has quit [Ping timeout: 260 seconds]
EchelonX has quit [Quit: Leaving]
jn has quit [Ping timeout: 245 seconds]
jn has joined #riscv
jn has joined #riscv
jn has quit [Changing host]
GenTooMan has joined #riscv
KombuchaKip has quit [Quit: Leaving.]
KombuchaKip has joined #riscv
stolen has joined #riscv
jacklsw has joined #riscv
vagrantc has quit [Quit: leaving]
<sorear>
muurkha: visibility and search order, mostly. the definition in the executable is guaranteed to be the one used at runtime, so there's no need to make provisions for interposition. you can get the same benefits in shared libraries for visibility=hidden symbols
<sorear>
the kernel doesn't use ELF dynamic linking semantics but the same rules apply; modules can't override a symbol defined in the kernel itself, so the kernel can use PC-relative accesses to its own symbols without involving a GOT
worky is now known as willy
<willy>
sorear: my impression is that chiplets aren't mix-and-match yet. there seem to be various competing efforts to define a standard, but for now i haven't seen anyone claim that they can integrate chiplets from different manufacturers into the same package
<sorear>
i've yet to meet anyone with a wirebonder so this is far outside the scope of things that it is useful for me to have an opinion on
<dh`>
losing a register as such is a compiler bug; the compiler ought to be able to spill the global offset pointer like any other value, but for a long time gcc couldn't and I think it still can't
<dh`>
(to be fair, there are complications on some targets because of silly assembler behavior)
<jrtc27>
gcc is no longer stupid for i386
<jrtc27>
but it took an absurdly long time to resolve that one
<jrtc27>
and i386 was long obsolete by the time it happened
jacklsw has quit [Ping timeout: 260 seconds]
<dh`>
good to hear, about time
stolen has quit [Quit: Connection closed for inactivity]
BootLayer has joined #riscv
jacklsw has joined #riscv
unsigned has joined #riscv
handsome_feng has joined #riscv
ldevulder has joined #riscv
MarvelousWololo has quit [Read error: Connection reset by peer]
danilogondolfo has joined #riscv
cousteau_ is now known as cousteau
ldevulder has quit [Quit: Leaving]
ldevulder has joined #riscv
<bjdooks>
bah, looks like sifive are finally retiring my login :(
Gravis has quit [Ping timeout: 252 seconds]
<bjdooks>
happy debian riscv day
elastic_dog has quit [Ping timeout: 246 seconds]
wingsorc has quit [Ping timeout: 245 seconds]
elastic_dog has joined #riscv
jacklsw has quit [Ping timeout: 252 seconds]
bjoto has quit [Ping timeout: 240 seconds]
Gravis has joined #riscv
bjoto has joined #riscv
Gravis has quit [Ping timeout: 250 seconds]
Andre_Z has joined #riscv
<Esmil>
geertu: I updated the visionfive branch with the non-coherent dma support based on Arnd and Prabhakar's patches. I tried to order the patches so they only get ugly from "clk: starfive: jh7100: Keep more clocks alive" and onwards
<Esmil>
arnd: that branch contains a version of your dma-mapping series with all the stuff the kernel test robot found fixed btw.
<mps>
anyone made unified patch for VF v1 and v2 for linux-rc
<Esmil>
mps: i haven't done it yet, but you could just take that branch and apply all the latest jh7110 patches from the mailing list on top
<mps>
Esmil: nice, and thanks. will try this evening
<mps>
Esmil: another question, do you or someone else plan to push patches for v1 to mainline
<Esmil>
mps: yeah, so with these updated patches for the non-coherent i think both Palmer and Conor seemed happy to take them last we spoke about it here, but they still depend on arnd and Prabakhars patchset landing first
<mps>
Esmil: this is good news. thanks for info
billchenchina has joined #riscv
joev1 has quit [Ping timeout: 244 seconds]
joev1 has joined #riscv
heat has joined #riscv
<Esmil>
mps: btw. remember to enable CONFIG_ERRATA_STARFIVE_JH7100 and CONFIG_USB_CDNS3_STARFIVE when you're building for the vf1
<mps>
Esmil: sure and thanks for info
<mps>
usually I run make oldconfig and it ask for new options
<courmisch>
are people still using VF1? mine hasn't seen current for several months
<geertu>
Esmil: thx, I had noticed the branch was updated ;-) Will test tomorrow...
<geertu>
Esmil: Looks like you missed the runtime fixes for arm64. Patch sent.
<geertu>
Esmil: Please ignore the Fixes tag in the patch I sent, it points to the commit in your jh7100-dmapool branch.
<geertu>
courmisch: Dunno about VF1, but there's also Starlight aka BeagleV Beta
xypron_ has quit [Ping timeout: 260 seconds]
merry has quit [Read error: Connection reset by peer]
merry has joined #riscv
BootLayer has quit [Quit: Leaving]
<Esmil>
geertu: ah, thanks! i've updated the visionfive branch with that now
xypron has joined #riscv
<unlord>
hi
<unlord>
how do I specify the vector version v1.0 when using qemu-system-riscv64
<unlord>
I get this warning when running it now: vector version is not specified, use the default value v1.0
<mps>
courmisch: some people have only VF1
<dzaima[m]>
unlord: vext_spec=v1.0 in -cpu
<mps>
because this I'm trying to upgrade kernel for alpine
<unlord>
dzaima[m]: awesome, thank you
stolen has joined #riscv
handsome_feng has quit [Quit: Connection closed for inactivity]
esv has quit [Remote host closed the connection]
xypron has quit [Ping timeout: 258 seconds]
jmdaemon has quit [Ping timeout: 244 seconds]
BootLayer has joined #riscv
kaol has joined #riscv
heat has quit [Remote host closed the connection]
heat has joined #riscv
<unlord>
is there a way to get faster IO with qemu?
handsome_feng has joined #riscv
<unlord>
also, I just booted 6.5.0-rc2 and am now getting an Illegal Instruction on vsetvli
<unlord>
is there a .config I need to set to enable vector?
Andre_Z has quit [Quit: Leaving.]
<mps>
unlord: RISCV_ISA_V
<mps>
and RISCV_ISA_V_DEFAULT_ENABLE
<unlord>
hmm, the issue is I am getting TOOLCHAIN_HAS_V = n when I make menuconfig
<mps>
so you need new toolchain
<unlord>
how new? I was building kernel with V support using a much older patchset
<mps>
gcc and binutils
unsigned has quit [Quit: .]
<unlord>
ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- make menuconfig showed those configuration options
<unlord>
I hope gcc-11 is new enough
<mps>
iirc no
<Tenkawa>
I think you need 13
<mps>
yes, 13 have it
<Tenkawa>
I have for most things I have been working on
<unlord>
looks like I have riscv64-unknown-linux-gnu-gcc-12.1.1 and riscv64-unknown-linux-gnu-gcc-13.0.0
<sorear>
why do we go to so much trouble to use INSN_R macros instead of asm("vwhatever") if the whole thing is gated on TOOLCHAIN_HAS_V anyway?
<sorear>
the vector support in the kernel _ought_ to work with any otherwise supported version of gcc/binutils
<sorear>
re. faster IO: depends on the kind of IO and what bottlenecks you're seeing
<unlord>
nice, building a new kernel fixed the Illegal Instruction on vsetvli
<unlord>
thank you
<Tenkawa>
excellent
<sorear>
the closest thing to blanket advice is "make sure you're using virtio" but I don't think the current qemu riscv machines support anything else
<Tenkawa>
sorear: is qemi-virtio supported "in
<Tenkawa>
er "in" the riscv guest kernel?
<Tenkawa>
er qemu-vrtio (I'm having a great typing morning)
<sorear>
i've definitely built kernels with virtio support, and the default "virt" machine uses virtio for all non-platform devices
<Tenkawa>
oh good
<mps>
Esmil: I was impatient and build 6.5-rc3 according your advice, make patch from your visionfive branch and applied to vanilla mainline and on top also patches from aurel32
<sorear>
it's theoretically possible that the hifive_u machine emulates the real ethernet MAC but I don't think so
<Tenkawa>
It was fickle back in early arm days so I wasn't sure how well riscv handled it
<mps>
Esmil: boots and works on VF1 and VF2
<sorear>
count yourself lucky if you don't remember htif-blk
<Tenkawa>
heard of it I think but never used it (only been using risc-v a few months)
<mps>
for long I use '-netdev user,id=n1 -device virtio-net-pci,netdev=n1' with riscv64 qemu
<sorear>
getting pcie and virtio to actually work in the guest kernel took a couple years, there were special riscv-specific virtual devices before that (mid-late 201x) that required a qemu fork and tended to deadlock after a few hours
<Tenkawa>
I was doing arm a long time ago....
<bjdooks>
there is also virtio platform devices too
<Tenkawa>
mips: you got that kernel up on a git by chance?
<Tenkawa>
mips: I'd like to try it out
<mps>
Tenkawa: mips or mps?
<Tenkawa>
mps: I assume you are building for VF2 right?
<Tenkawa>
you mentioned VF1 and 2
frkzoid has joined #riscv
<mps>
Tenkawa: latest built kernel is for vf1 and vf2
<mps>
how big files are allowed on ix.io
<Tenkawa>
I have Esmil + aurel32 + some of my own changes on a 6.4 kernel currently.. I'd be curious to see how it runs on 6.5
<mps>
Tenkawa: just tested 6.5-rc3 with these patches on both, works fine
<Tenkawa>
mps: microsd emmc or nvme?
<mps>
booted from mmc, but on vf2 emmc is seen
<Tenkawa>
That's part of the "gotcha"... I have NVMe fixes in my source
<mps>
still didn't bought nvme
<Tenkawa>
I'm running off nvme only
<Tenkawa>
Both my VF2 and Star64 do now
<mps>
Tenkawa: for some alpine users these patches worked for nvme but for some doesn't
freakazoid332 has quit [Ping timeout: 260 seconds]
<mps>
could be nvme devices problem or power supply
<Tenkawa>
indeed
<Tenkawa>
I "know" I have one dfrive that will not play nice
<Tenkawa>
er drive
<mps>
I can put patches on my web server later and send url to you if you are interested to try
<Tenkawa>
Definitely
<mps>
ok, when I come back home, in about 1-2 hours
<Tenkawa>
I also learned the lesson of not putting drives used for GPT in "Performance/Best" mode.... just don't do it
<Tenkawa>
Unless someone here knows how to have GPT "not" use 4096 sector size....
<Tenkawa>
heh
stolen has quit [Quit: Connection closed for inactivity]
MarvelousWololo has joined #riscv
Andre_Z has joined #riscv
xypron has joined #riscv
jacklsw has joined #riscv
<jrtc27>
sorear: now if only spike would do virtio... :)
<jrtc27>
at least it has a real uart now rather than the htif?
<jrtc27>
that thing was awful
Leopold has quit [Ping timeout: 260 seconds]
heat_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
markus-zzz has joined #riscv
<markus-zzz>
sorear: yesterday you mentioned that 'i feel like this should be easy to fix, especially now that linux maps itself with 4K pages to avoid mapping firmware-reserved areas'. Do you have any references to when that went in? I've been looking around a bit but was only able to find
<sorear>
markus-zzz: create_linear_mapping_range has the logic I was thinking of, although it looks like different logic is used earlier in boot, you may have gotten farther than I did
<unlord>
So, my qemu-system-riscv64 is really slow to compile packages, much slower than I would expect even with emulated hardware
<unlord>
if I think it is IO, is there a way I could test?
<courmisch>
user-moed QEMU in a chroot is probably faster
<unlord>
will that still boot this 6.5 kernel?
<courmisch>
it will use your host kernel, so if that's not OK for your use case, don't
<unlord>
my host is x86_64
<sorear>
try the build in a tmpfs with all build output redirected to a file. this will not use any IO; if it's faster, IO was your problem, if it isn't, IO wasn't
<courmisch>
unlord: but is it 6.5 and do you need 6.5 for anything?
<sorear>
"user-moed QEMU" means qemu-riscv64, no "system", or --target-list=riscv64-linux-user at configure time
esv has joined #riscv
<sorear>
it runs one process using emulation in userspace, but the kernel (incl. IO and memory management, which is the bigger problem) is just your host kernel and runs at full speed, unemulated
<courmisch>
it can run any number of processes even. As long as you don't need DBus, X11/WL or /proc, it mostly just works
<unlord>
maybe this code is wrong, I will try again
<courmisch>
in system mode, hwcap is filled by the emulated guest kernel
<courmisch>
in user mode, it's filled by QEMU system call emulator
<conchuod>
> I had a /proc/cpuinfo with V but was getting an Illegal Instruction from the kernel
<conchuod>
Had you built a v6.5-rcN kernel, but not set the config option to build in the vector code? It should be automatically enabled.
<unlord>
conchuod: correct
<courmisch>
does gcc even support -mcpu=native on RISC-V yet? why do you need run-time detection at compilation time?
<unlord>
I first built the kernel with LLVM=1 ARCH=riscv defconfig all and this did not enable RISCV_ISA_V=y
<courmisch>
I think you need bleeding edge LLVM for V support
<conchuod>
Ahh, right. Because ?IAS? doesn't support .arch yet.
<conchuod>
Remi is right though, /proc/cpuinfo is crap :)
<courmisch>
RVV is very much a GCC/binutils affair at the moment
<jrtc27>
that's a bit disingenuous
<jrtc27>
LLVM has had far better RVV support for far longer
<jrtc27>
it's just .option arch that it lacked, because binutils is trigger-happy and merges things before the spec gets finalised
<jrtc27>
(.option arch, mapping symbols, ...)
<jrtc27>
to the extent that they border on forcing our hands as spec authors, since it's then a lot harder to change proposals that people have gone and put into production...
junaid_ has quit [Ping timeout: 260 seconds]
<courmisch>
maybe binutils was rushing too much, but it looks like LLVM didn't care to progress the merge request until a certain large company started asking
<jrtc27>
binutils has some very questionable behaviour for .option arch, -foo, as well as for .option arch, a, b, c
<jrtc27>
LLVM cared, the patch author didn't
<jrtc27>
IIRC
<jrtc27>
but also, yes, if nobody's pushing for something to happen, it won't happen
<jrtc27>
that's how software development works
<courmisch>
not just anybody
<courmisch>
the issue was flagged in FFmpeg almost a year ago, not that that did anything
<jrtc27>
in case you didn't notice, ffmpeg and llvm developers aren't the same people
<jrtc27>
so, congrats for ffmpeg developers?
<jrtc27>
if they don't say "hey we need this" to us then nothing's going to happen on the llvm side, is it
<conchuod>
courmisch: who is "certain large company"? Google?
<jrtc27>
yes
<courmisch>
conchuod: I think but I don't want to name without proof
<jrtc27>
look, my point is, if your goal is to dunk on llvm you can go away
<jrtc27>
as that what it looks like you're trying to do here
<conchuod>
I don't think that's a fair representation of llvm development
<conchuod>
iirc, it was Nick that commented there, and he did so because either Nathan or I mentioned it.
<jrtc27>
and when we were told that there were people who saw it as important, we pushed it through
<jrtc27>
how things are supposed to work
<conchuod>
Yea
<jrtc27>
the problem was that nobody was pushing for it to be merged
<courmisch>
jrtc27: that's pretty rich from the person that started by calling me disingenous,
<jrtc27>
hell I even contributed to cleaning up the implementation
<jrtc27>
I was understating it
<jrtc27>
"RVV is very much a GCC/binutils affair at the moment" is demonstrably false
<jrtc27>
*using it in the linux kernel* is true-ish
<jrtc27>
but that's not what you said
<jrtc27>
anyway if you want to be like this again I have no interest in continuing to discuss this matter with you
<courmisch>
jrtc27: you're the one who insulted me, twice. I don't need to point you to the Libera Chat policies, now, do I?
Trifton_ has quit [Ping timeout: 264 seconds]
handsome_feng has quit [Quit: Connection closed for inactivity]
<jrtc27>
look, if you think me telling you you're wrong or that I feel like you're trying to attack a software project is insulting you, that's on you
<jrtc27>
I have not insulted you once here
<jrtc27>
so kindly stop being like this
<courmisch>
disingenous is not an adjective that applies to project, it applies to people
<courmisch>
and you are grossly misrepresenting my statement, since it was contextually obviously about the kernel
<courmisch>
(and whatever else Nathan may want to do, I'm guessing FFmpeg and/or dav1d)
<jrtc27>
yes, disingenuous is about people, because you made a statement that you meant to be about the kernel but you put more broadly about RVV
<jrtc27>
both kernel and userspace were being discussed
<jrtc27>
namely how to get a kernel that supported RVV userspace
<jrtc27>
so I think it's totally justified to say that it needs qualifying
<jrtc27>
but regardless, it's not an insult
meowray has quit [Changing host]
meowray has joined #riscv
<jrtc27>
I said "a bit disingenous"
<jrtc27>
as in "a bit misrepresentative of the situation"
<courmisch>
come on, this is IRC. People aren't going to put all the circumstancial disclaimers at every line.
<courmisch>
by "RVV" I somewhat obviously meant assembler in scenarii that require run-time detection
<courmisch>
I daresay that that would have been unreasonably long
<courmisch>
it was totally unwarranted to accuse me of dunking on LLVM. I had even pointed out already that it *did* work in bleeding-edge LLVM versions
junaid_ has joined #riscv
junaid_ has quit [Client Quit]
junaid_ has joined #riscv
<courmisch>
now if you mean autovectorisation, LLVM seems better than GCC in some respects, but it also seems worse in others, based on the last godbolt comparison on this channel a couple weeks ago. I don't pretend to know much about either of them.
junaid_ has quit [Remote host closed the connection]
junaid_ has joined #riscv
<whitequark[cis]>
what the heck happened here
Trifton_ has joined #riscv
<sorear>
unlord: there is no such function as hwcap(), do you mean hwprobe() or getauxval(AT_HWCAP)?
whitequark[cis] has quit [Quit: Reconnecting]
<sorear>
unlord: if you are expecting qemu's TCG support of rvv 1.0 to be in any way fast, or even faster than TCG execution of scalar code, you will be disappointed
whitequark[cis] has joined #riscv
<courmisch>
IIUC, he's just trying to set up a native-like build environment
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
Pierce[m] has quit [Quit: Bridge terminating on SIGTERM]
psydroid[m] has quit [Quit: Bridge terminating on SIGTERM]
[0x4A6F][m] has quit [Quit: Bridge terminating on SIGTERM]
jrtc27[m] has quit [Quit: Bridge terminating on SIGTERM]
dzaima[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Client Quit]
sorear[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #riscv
sorear[m] has joined #riscv
whitequark[cis] has joined #riscv
jrtc27[m] has joined #riscv
dzaima[m] has joined #riscv
Pierce[m] has joined #riscv
[0x4A6F][m] has joined #riscv
psydroid[m] has joined #riscv
<sorear>
unlord: virtfs is a feature for seamless host/guest filesharing. it is an ease of use feature not a performance one, although I haven't benchmarked it so I can't say how slow it is or isn't
<courmisch>
is there a RV equivalent to Armie (implementing missing instructions in SIGILL) and is it something that could have any practical use?
<courmisch>
I'd considered it, but then I thought it would be so attrociously slow as to be useless
<courmisch>
atrociously*
<sorear>
you cannot safely do that in user space because there's no way for the higher layers to communicate "every instruction from X extension causes a SIGILL and has no other side effects"
<sorear>
vendors are allowed to put custom extensions in standard extension space, vendors are allowed to implement draft extensions, RVI itself has conflicting use of opcode space...
<courmisch>
in general yes, but if you know your CPU
<sorear>
preferred approach is to do it in M-mode
<courmisch>
you wouldn't want to emulate RVV in M mode, though, I think
<courmisch>
in fact, you couldn't, because M mode doesn't know about context switches
<sorear>
opensbi does this for misaligned accesses / Zicclsm and non-canonical fences (required by the text of the spec but not tested by the conformance suite and, surprising no one, accidentally omitted from C906)
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
sorear[m] has quit [Quit: Bridge terminating on SIGTERM]
dzaima[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
Pierce[m] has quit [Quit: Bridge terminating on SIGTERM]
psydroid[m] has quit [Quit: Bridge terminating on SIGTERM]
jrtc27[m] has quit [Quit: Bridge terminating on SIGTERM]
[0x4A6F][m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #riscv
sorear[m] has joined #riscv
junaid_ has quit [Quit: leaving]
<sorear>
all you actually need is for mstatus.VS to be implemented as two writable bits that control nothing, then when the kernel context-switches the vector unit it'll trap into M-mode
<courmisch>
also armie doesn't need privileges...
whitequark[cis] has joined #riscv
jrtc27[m] has joined #riscv
dzaima[m] has joined #riscv
Pierce[m] has joined #riscv
[0x4A6F][m] has joined #riscv
<courmisch>
sorear: I don't really follow. Upon preemptive context switch, you need to save the vectors somewhere. M can't realistically track each user task
psydroid[m] has joined #riscv
<courmisch>
oh, you mean to trap-and-emulate also the kernel mode?
<sorear>
yes
<courmisch>
yeah that could work but then you need to convince the kernel to enable V support... for all processes
<sorear>
it was quite common ca. 2018 to do this for the F/D extensions and bbl has the feature, but it never made it into opensbi
<sorear>
as far as the kernel is concerned the hardware has V.
<courmisch>
I mean, it's probably better to enable this on select processes, than system-wide
<courmisch>
lying to kernel that V is supported is maybe not the bestest idea
<courmisch>
I could sorta see the appeal of doing that for H, but not really for V
coughlanio has joined #riscv
junaid_ has joined #riscv
<sorear>
courmisch: that wasn't a personal attack
<sorear>
jrtc27: maybe lead with "demonstrably false" instead of "disingenuous" - the former doesn't make unfalsifiable claims about other people's intentions
<sorear>
jrtc27: also, your advice is excellent, please follow it next time you want to talk about "andes' garbage core" in the middle of another conversation ... we do have andes people here
junaid_ has quit [Quit: leaving]
Andre_Z has quit [Quit: Leaving.]
BootLayer has quit [Quit: Leaving]
wingsorc has joined #riscv
heat__ has joined #riscv
junaid_ has joined #riscv
heat__ has quit [Remote host closed the connection]
heat_ has quit [Ping timeout: 260 seconds]
heat__ has joined #riscv
junaid_ has quit [Ping timeout: 260 seconds]
heat has joined #riscv
heat__ has quit [Read error: Connection reset by peer]
<muurkha>
jrtc27[m]: "disingenuous" doesn't just mean "misrepresentative of the situation"; it means "intentionally misrepresenting the situation in a way only an idiot could believe was coorrct". it's an extremely insulting thing to say in most contexts
<muurkha>
most insults stick to either attacking someone's integrity or their relevant abilities; "disingenuous" is extremely clever in simultaneously attacking both, like a fork in chess: if the person being insulted protests that in fact they are being perfectly honest, it magically morphs into a deep dis of their intellectual capacity. also from the beginning it's an attack on the intelligence of anyone foolish
<muurkha>
enough to agree with their (supposedly dishonestly) stated position
<muurkha>
s/coorrct/correct/
<muurkha>
maybe you could say that a story someone told at The Moth or a similar venue, where the presumption is that everything is fiction, was "disingenuous" without being insulting. but in many, perhaps most, social contexts, both honesty and intelligence are highly valued, so it is almost always very insulting