<drewfustini>
anyone know if it is possible to pin riscv_clock_next_event() in drivers/clocksource/timer-riscv.c to a single cpu? The idea being that sbi_set_timer() would always get called on the same cpu.
<palmer>
drewfustini: we've gone back-and-forth on the per-CPU clocks for a while, IIRC we ended up in a spot where we can't do that sort of thing
KombuchaKip has joined #riscv
<drewfustini>
Thanks... I haven't ftrace'd it yet, but would you expect sbi_set_timer() to be called on a random cpu?
<palmer>
drewfustini: looks like we have per-cpu clock events and a single global clock source, with the coupling being the ISA requirement that rdtime is synced between harts. So I think it should be possible to schedule a clock event on a hart, but by default they'll end up scheduled on arbitrary harts. I forget if it ends up being the same every time.
<palmer>
(there's also some other calls of sbi_set_timer, not as sure about those)
<palmer>
they're all in kernel/sbi.c, though, so they're probably just shims/emulation type stuff
junaid_ has quit [Ping timeout: 246 seconds]
lainon has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<drewfustini>
Thanks for the explanation. It's odd that sbi_set_timer is not in available_filter_functions. It's not "inline". I've just added noinline to be sure gcc is not inlining it.
<drewfustini>
I wanted to see which cpus call it
Tenkawa has quit [Quit: Was I really ever here?]
Tenkawa has joined #riscv
<palmer>
anything left for the merge window? I'm poking through for small stuff on patchwork, but I'm pretty much running out
jacklsw has quit [Ping timeout: 245 seconds]
<drewfustini>
re: sbi_set_timer() above, well at least I can trace riscv_clock_next_event() and that shows pretty much even distribution across all harts
<palmer>
OK, I guess then the question would be whether Linux is scheduling events on all harts or just one
Leopold has quit [Remote host closed the connection]
lainon has joined #riscv
Leopold has joined #riscv
tlwoerner has joined #riscv
Andre_Z has quit [Quit: Leaving.]
prabhakarlad has quit [Quit: Client closed]
jmdaemon has joined #riscv
<courmisch>
any news of hwprobe in glibc?
<jrtc27>
I was hoping glibc would wrap the interface up into something less awful
<jrtc27>
though I guess one could always layer a __riscv_get_extension(3) on top of a __riscv_hwprobe(2)
___nick___ has joined #riscv
<courmisch>
I doubt that that will happen, unless you (or someone else with the same strong opinion) submits such an interface rather soon
iooi has quit [Read error: Connection reset by peer]
<courmisch>
there was already a proposal to just wrap the syscall+vdso 1:1, though it was rejected as the kernel ABI was not released then
iooi has joined #riscv
<courmisch>
and to be fair, having a completely different glibc call vs syscall is a pain of its own, now that the kernel interface is what it is
<jrtc27>
yes, but the syscall can never be cross-platform and is hostile to vendor extensions
<courmisch>
means you can't just fallback to hand-written syscall for old glibc or non-GNU libc
<jrtc27>
it is the epitome of "works for me" linux development
<courmisch>
I won't deny that it's a bit clunky and weird and it wasn't my idea
<courmisch>
but I don't see how you can make portable API for an intrinsically ISA-specific thing
<jrtc27>
across OSes!
<jrtc27>
clearly "what RISC-V extension do I have" doesn't translate to x86
<courmisch>
hmm. well, the aarch64 approach is kind of nice, but it's derived from the ISA. RV has no equivalent
<courmisch>
and not all OSes implement the aarch64 ID3 emulation either
<jrtc27>
on aarch64 you can look at AT_HWCAP for ELF platforms
<jrtc27>
which isn't universal but gets you most OSes
jmdaemon has quit [Ping timeout: 246 seconds]
<courmisch>
AT_HWCAP has long since run out of bits on aarch64
<courmisch>
even AT_HWCAP2 is almost full
<jrtc27>
but a random linux syscall tied to linux notions of cpu sets and data structures is not the solution
<courmisch>
hence the TID3 trick
<jrtc27>
no it's not
<jrtc27>
not if you are dealing with 64-bit
<jrtc27>
I'm not saying AT_HWCAP* is a *good* approach, and definitely not one that fits RISC-V
<jrtc27>
but it has its benefits
<jrtc27>
and in designing __riscv_hwprobe, those have been eschewed
<jrtc27>
because linux devs do not care about other OSes
<jrtc27>
and so when other OSes come and do something else, out of necessity, that's a pain for everyone
<jrtc27>
because now software needs porting to multiple approaches
<jrtc27>
and toolchains need to have multiple paths for automatic function multiversioning
<courmisch>
did you raise those issues on the ML in time though?
<jrtc27>
yes
<jrtc27>
many many times
<sorear>
the linux syscall is nowhere near as futureproof as I'd like since it assumes the set of possible CPUs and their extensions is a boot-time constant, which will fall over if you have hotplug with any degree of inter-generation or inter-vendor electrical compatibility
<jrtc27>
that is my first email on the subject, on the v2
<sorear>
I'm not terribly fond of the new ULL_BIT(63) proposal either since some chips will have extensions from multiple vendors, or extensions that came from an open-source project and therefore have a 0 mvendorid (Xpulp/Xcv)
<jrtc27>
plus on IRC and in private communications with RVI people
<courmisch>
sorear: I don't really see how the syscall makes that assumption? you mean the current implementation maybe, but what's to prevent changing the implementation without changing the interface
<courmisch>
and any software will explode if you remove extension from under them at run-time
<courmisch>
Linux arm64 specifically refuses to touch a hot-plugged CPU if it has lower capabilities than the boot CPUs
jmdaemon has quit [Ping timeout: 246 seconds]
jmdaemon has joined #riscv
<gurki>
are there plans to have mixed-capability riscv-cpus?
<gurki>
(genuine question, didnt hear about these yet)
<courmisch>
IIRC, VF1 had a smaller core, but it wasn't used for anything?
Narrat has joined #riscv
<jrtc27>
the sifive u74-mc has an rv64imac core alongside the rv64gc cores, yes
<jrtc27>
(ditto for the older u54-mc)
<jrtc27>
it doesn't have mmu parts to be able to run your OS kernel, though
<jrtc27>
it's really intended as a firmware management core
<courmisch>
and TH1520 has a C906... for audio, was it?
<courmisch>
that *would* have Sv, no?
<sorear>
a couple of the bouffalo chips have separate rv64 and rv32 cores, but the rv32 cores are no-mmu
<sorear>
the cv1800b / milk-v duo supposedly has 2x RV64 C906, only one of which supports (0.7.1) vectors; I think this is the only current case with mixed capability between MMU-capable cores
<gurki>
thanks for all that info :)
<sorear>
"plans" implies you think we know the future, which ???
<sorear>
very few people here work for hardware companies, and none of them are allowed to talk about it, remember that
<muurkha>
:(
<gurki>
sorear: well i obv was wrong to begin with since you could already name implementations, even some with mmu ;)
<jrtc27>
and teach them about RISC-V-the-ISA vs RISC-V-the-platform
JanC has joined #riscv
<muurkha>
apropos of what?
awita has quit [Remote host closed the connection]
lainon has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Trifton_ has quit [Remote host closed the connection]
pecastro has joined #riscv
<sorear>
some of the requirements in that adoc are bizarre, what's the use case supposed to be for requiring PMP/IOPMP or Zam in 16 byte regions
<sorear>
(last I checked Zam _forbids_ cache-line-crossing atomics from working which seems to make it a net negative)
<sorear>
I remember back in the mid-2010s a lot of people were convinced "the kernel can overwrite the boot loader" was somehow a security hole but I thought we'd moved past that
<muurkha>
well, it can be, depending on your threat model
lainon has joined #riscv
dh` has quit [Read error: Connection reset by peer]
dh` has joined #riscv
<sorear>
yes, and it's the responsibility of the platform designers to know if "platform firmware continues to operate regardless of loaded OS" is a requirement, that's not something that makes sense to dictate in an *OS-facing* specification
<sorear>
such a requirement would make sense in a *board designer facing* SoC specification - you can write fan control firmware, say, and know that nothing the OS does will interfere with it
<muurkha>
well, I was thinking in evil-maid terms
<muurkha>
or rootkit terms
<muurkha>
I would very much like to know that if Sony manages to get a rootkit into my kernel they can't keep me from installing a non-compromised OS
Narrat has quit [Quit: They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.]
<muurkha>
one of my wife's classmates just got malware that installs in his UEFI Flash
<muurkha>
but there are plenty of computers where it doesn't make any sense to try to protect boot loaders from maliciously subverted kernels
Tenkawa has quit [Quit: Was I really ever here?]
<sorear>
again, a useful promise to make to system integrators, not a useful promise to make to OS authors
<muurkha>
maybe it's useful for the OS authors to know they can't overwrite the firmware
iooi has quit [Read error: Connection reset by peer]
iooi has joined #riscv
<sorear>
you mess with reserved memory (clearly identified by both DT and UEFI) and you get to keep both pieces, that's the OS authors' view
JanC has quit [Ping timeout: 260 seconds]
jmdaemon has joined #riscv
<jrtc27>
I think the issue here is it's trying to be all things at once