<sorear>
yikes. arguably rdtime would be better, since it's typically an independent clock
davidlt has quit [Ping timeout: 268 seconds]
davidlt has joined #riscv
<aurel32>
i don't see why it would be better to get some entropy. Also rdtime doesn't guarantee that the lower bits change between successive calls
czy has quit [Remote host closed the connection]
heat has joined #riscv
iooi has quit [Ping timeout: 252 seconds]
czy has joined #riscv
<sorear>
there's no formal requirement of that for rdcycle, either, and rdcycle is more likely to have lower bits that change deterministically if you do two rdcycles with a bunch of divides between them
<sorear>
the call site and the paper linked from there talk about nondeterministic execution time of divide instructions which ??? divides are implementation defined but every divider I've seen has time that only depends on the operands
<jrtc27>
(though maybe rdcycle is meant to be implicitly semi-dependent on all prior instructions in program order?)
<jrtc27>
(otherwise one could hoist rdcycle to be as early as the previous rdcycle which seems not so useful?)
<jrtc27>
sure, but not the rdcycle itself
<sorear>
server-soc requires a time update frequency of 100MHz, hifive has a comically low time update frequency but also comically slow rdtime so it works out
<sorear>
if you're very "lucky" and have a banked physical register file you might be able to get a few bits of renamer state entropy out of that loop, otherwise it's just smoke and mirrors around the cycle counter at entry
pakcjo has quit [Ping timeout: 268 seconds]
heat has quit [Remote host closed the connection]
<sorear>
non-negligible chance of an interrupt arriving during the 50k back to back divides which helps too
<bjdooks>
anyone else planning on going to EOSS in Seattle in April
Andre_Z has quit [Quit: Leaving.]
prabhakar has joined #riscv
prabhakarlad has joined #riscv
MaxGanzII_ has quit [Ping timeout: 255 seconds]
foxbat_ has quit [Ping timeout: 272 seconds]
foxbat has joined #riscv
EchelonX has joined #riscv
EchelonX has quit [Client Quit]
EchelonX has joined #riscv
radu242753435752 has joined #riscv
Tenkawa has joined #riscv
radu242753435752 has quit [Ping timeout: 255 seconds]
EchelonX has quit [Quit: Leaving]
prabhakar has quit [Ping timeout: 255 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
mlw has quit [Remote host closed the connection]
prabhakarlad has joined #riscv
prabhakar has joined #riscv
MaxGanzII_ has joined #riscv
suqdiq has quit [Quit: Ping timeout (120 seconds)]
suqdiq has joined #riscv
ezulian_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
heat has joined #riscv
ezulian has quit [Ping timeout: 272 seconds]
<palmer>
aurel32: I think for entropy you're going to need to call the kernel at some point, there's no good way to do it in general on RISC-V
<palmer>
I guess with the Zkr (or wherever the random bits ended up) we have an instruction for it, so we could trap/emulate that? then it's just a matter of making sure implementations actually trap
jacklsw has joined #riscv
BootLayer has joined #riscv
ntwk has quit [Read error: Connection reset by peer]
foxbat has quit [Ping timeout: 252 seconds]
<sorear>
that sounds like Sstrict which is a profile option
<sorear>
but given that the current version is srand(time(0)^getpid()) tier
Andre_Z has joined #riscv
Noisytoot has quit [Ping timeout: 256 seconds]
dramforever[m] has joined #riscv
<dramforever[m]>
on the kendryte k230, rvv load/store instructions can't access mmio registers. is this allowed?
<dramforever[m]>
like i can mmap /dev/mem and if i point it to say the serial port registers, if i do a scalar load it loads, if i do a vector load it does a load access fault
<courmisch>
allowed I dunno, but sounds kind of reasonable?
pakcjo has quit [Ping timeout: 255 seconds]
mlw has joined #riscv
<dramforever[m]>
> I/O regions can specify which combinations of read, write, or execute accesses to which data widths are supported.
<dramforever[m]>
that's from the pma stuff
<dramforever[m]>
and the v spec says something for misaligned accesses
shamoe has joined #riscv
<dramforever[m]>
like it does very much look like if vector load/store is can access io it's well-defined
foxbat has joined #riscv
pakcjo has joined #riscv
Noisytoot has joined #riscv
jmdaemon has joined #riscv
billchenchina has joined #riscv
jacklsw has quit [Ping timeout: 272 seconds]
<dramforever[m]>
i had someone porting software to t-head stuff telling me they found pulseaudio was trying to memcpy stuff, and it crashes because they've got an rvv memcpy
<dramforever[m]>
i think that was on c910, so pre-rvv1.0, but i'm pretty sure this is the same problem
<dramforever[m]>
and i'm also not entirely sure how the original memcpy got through... they say "strong order", which is weird stuff about t-head pte attributes
<dramforever[m]>
so maybe it's "no rvv if strong order by pma or by page table"?
<palmer>
dramforever[m]: if the vendor says it's allowed then it is ;)
<dramforever[m]>
i'm wondering just mostly like, can it be not allowed?
<palmer>
sure, if the ISA (or some github issue or whatever) says it's not allowed then it's now allowed -- at least until some HW vendor says it is allowed, then it is
<palmer>
RISC-V really just isn't an ISA, it's just marketing
<dramforever[m]>
it's fence.tso all over again
<palmer>
sound like we'll need some extra magic for the T-Head cores. Do you know if there's any T-Head documentation of that behavior, or if it's just that comment?
<palmer>
ya, we've been through this a bunch of times with RVI. I've stopped even bothering to write stuff down any more, it's too crazy over there
<dramforever[m]>
popcorn day when upstream glibc adds rvv memcpy and it breaks all sorts of userspace drivers
<dramforever[m]>
i think maybe the c908 docs says this but i also don't have c908 docs
<palmer>
this is the k230? their product page is just linking back to their home page now, and that's all bitcoining mining (not AI, which I thought this was)
<dramforever[m]>
wonder if this is not officially out yet
<palmer>
pretty sure I saw product pages for it at some point, I always check that chips are real before merging stuff (there's way too much fake stuff in RISC-V land these days)
<jrtc27>
(uh, ignore the specific message link, that was arbitrary and unintended)
<dramforever[m]>
that's, one of the things rvv shouldn't have a problem with right? since you can load and store individual bytes and ask the core to figure it out
<dramforever[m]>
from what i can tell c908 does just not even try to access device memory and just fails it with a load/store access fault, but idk how to verify that
<dramforever[m]>
i suppose in t-head speak SO "strong ordered" means nR, and B "bufferable" means E, so "strong ordered" is nGnRnE or nGnRE
<palmer>
dramforever[m]: I think a reasonable argument could be made there. The ISA defines the V stuff as acting like loops of scalar instructions, so I'd argue that mandates this works
<palmer>
is doesn't, though, so we'll have to live with it ;)
epony has quit [Remote host closed the connection]
epony has joined #riscv
BootLayer has quit [Quit: Leaving]
foton has joined #riscv
ntwk has joined #riscv
foton has quit [Quit: %Bye, bye, ...%]
foton has joined #riscv
foton has quit [Remote host closed the connection]
foton has joined #riscv
Andre_Z has joined #riscv
foton has quit [Quit: %Bye, bye, ...%]
Leopold_ is now known as Leopold
davidlt has quit [Ping timeout: 264 seconds]
mlw has quit [Ping timeout: 264 seconds]
ntwk has quit [Quit: ntwk]
ntwk has joined #riscv
Andre_Z has quit [Quit: Leaving.]
unnick has quit [Ping timeout: 240 seconds]
unnick has joined #riscv
crossdev has quit [Remote host closed the connection]
Starfoxxes has joined #riscv
jobol has quit [Quit: Leaving]
psydroid has quit [Remote host closed the connection]
shamoe has quit [Quit: Connection closed for inactivity]