davidlt has quit [Remote host closed the connection]
davidlt has joined #riscv
Armand has joined #riscv
Armand has quit [Client Quit]
armand_ has joined #riscv
armand_ is now known as Armand
rsalveti has joined #riscv
JanC is now known as Guest1241
JanC has joined #riscv
Guest1241 has quit [Killed (platinum.libera.chat (Nickname regained by services))]
luca_ has joined #riscv
luca_ is now known as OwlWizard
Armand has quit [Read error: Connection reset by peer]
simpl_e has quit [Ping timeout: 255 seconds]
Armand has joined #riscv
OwlWizard has quit [Quit: OwlWizard]
Armand has quit [Read error: Connection reset by peer]
Armand has joined #riscv
Armand has quit [Remote host closed the connection]
Armand has joined #riscv
luca_ has joined #riscv
Armand has quit [Ping timeout: 255 seconds]
luca_ is now known as OwlWizard
handsome_feng has joined #riscv
crossdev has quit [Ping timeout: 246 seconds]
jobol has quit [Ping timeout: 268 seconds]
OwlWizard has quit [Quit: OwlWizard]
<sorear>
I appreciate how the edk2 bug reporting page actively says that you shouldn't report any bugs in edk2 unless you intend to participate fully in the mailing list
<sorear>
Not sure if I have that time commitment or if I should report bugs by private email instead
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #riscv
fuwei has joined #riscv
BootLayer has quit [Quit: Leaving]
ldevulder has quit [Read error: Connection reset by peer]
ldevulder has joined #riscv
mez62- has joined #riscv
crossdev has joined #riscv
<sorear>
ah, WhoAmI is not a problem because Boot Services owns the sscratch register (!), hopefully linux respects that
billchenchina- has quit [Remote host closed the connection]
Leopold has quit [Remote host closed the connection]
Leopold has joined #riscv
heat_ has joined #riscv
<ardb>
sorear: which scratch register is that?
<ardb>
re edk2 - did you have a bug in particular to report?
mez62- has quit [Ping timeout: 255 seconds]
BootLayer has joined #riscv
<sorear>
ardb: sscratch i.e. CSR_SCRATCH, the register linux uses to hold the current thread_info while executing in U-mode
<ardb>
EFI boot services are long gone when linux starts using that
<sorear>
ardb: the compare-exchange loops in MdePkg/Library/BaseSynchronizationLib/RiscV64/Synchronization.S are all missing their backbranches so they will misbehave if there is an interrupt or uarch event; i requested a bugzilla account via email
<ardb>
to check whether the reservation was honoured, right?
<sorear>
You don't need a back branch if the function is intended to have compare_exchange_weak semantics but in that case you do need to return the register written by sc, in this case a3, but a3 is just getting immediately discarded
* jrtc27
wonders if GetTime got fixed yet
<sorear>
there's no public spec for those functions but the ARM and LoongArch versions both loop depending on the sc result
<heat_>
jrtc27, which GetTime? for which platform?
<jrtc27>
at one point RT GetTime was using mtime
<ardb>
sorear: so SC puts a pass/fail in a3?
<sorear>
"reservation was honored" is slightly weird phrasing, the ISA spec says that the reservation can disappear at any time but will be used if it still exists (which has its own problems)
<jrtc27>
although I think that might only have been in a fork
<jrtc27>
and yes, you need to branch on a3 here
<ardb>
and restart at the LR i take it
<jrtc27>
it will eventually succeed (provided you meet the forward progress requirements) but there is zero guarantee it will the first time
<jrtc27>
in practice it probably does, but.. no
<jrtc27>
yeah
<jrtc27>
zero - succeeded, non-zero - failed, retry from load
<jrtc27>
and I strongly suspect there are some missing orderings or barriers here
<jrtc27>
given the aarch64 versions are full of dmb sy
<jrtc27>
(does EDK2 have a memory model?......)
<sorear>
my gut reaction is "do whatever InterlockedXyz does on NT for that architecture"
<ardb>
jrtc27: not sure what you'd be ordering against there
<ardb>
and i wouldn't take the aarch64 code as a reference there either
<jrtc27>
it's more likely to be correct that this riscv64 code
<ardb>
fair enough
<jrtc27>
the lack of a loop for lr/sc, a pretty basic thing to know about for lr/sc, does not fill me with confidence that the author so much as thought about memory ordering
<jrtc27>
yes, though you have to pick one of acq and rel
<jrtc27>
you can't have nothing
<ardb>
so why would you choose .rel and put the mf atfter?
<sorear>
so .rel prevents the cmpxchg from being reordered with any previous operation, and the following mf (fence rw,rw) prevents it from being reordered with any subsequent. looks like a sc cmpxchg
<heat_>
is there any difference between lr.aq and lr.aqrl?
ezulian has quit [Ping timeout: 260 seconds]
luca_ has joined #riscv
luca_ is now known as OwlWizard
<sorear>
that's kind of a can of worms, release consistency wasn't designed to allow release loads or acquire stores, but yes
kehvo has quit [Ping timeout: 260 seconds]
ezulian has joined #riscv
handsome_feng has quit [Quit: Connection closed for inactivity]
Armand has quit [Remote host closed the connection]
Armand has joined #riscv
OwlWizard has quit [Quit: OwlWizard]
Armand has quit [Ping timeout: 268 seconds]
ezulian has quit [Ping timeout: 272 seconds]
ezulian has joined #riscv
ezulian has quit [Remote host closed the connection]
balrog has quit [Quit: Bye]
jobol has joined #riscv
Armand has joined #riscv
Leopold has quit [Quit: No Ping reply in 180 seconds.]
Leopold has joined #riscv
Armand has quit [Remote host closed the connection]
armand_ has joined #riscv
vagrantc has joined #riscv
armand_ has quit [Remote host closed the connection]
Armand has joined #riscv
esv has quit [Remote host closed the connection]
esv has joined #riscv
motherfsck has quit [Quit: quit]
motherfsck has joined #riscv
crossdev has joined #riscv
Leopold has quit [Quit: No Ping reply in 180 seconds.]
dogukan has joined #riscv
Leopold has joined #riscv
davidlt has quit [Ping timeout: 260 seconds]
clemens3 has quit [Ping timeout: 260 seconds]
balrog has joined #riscv
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #riscv
Armand has quit [Ping timeout: 252 seconds]
JanC has quit [Ping timeout: 268 seconds]
JanC has joined #riscv
Leopold has quit [Quit: No Ping reply in 180 seconds.]
Armand has joined #riscv
BootLayer has quit [Quit: Leaving]
Leopold has joined #riscv
Armand has quit [Ping timeout: 272 seconds]
junaid_ has joined #riscv
Leopold has quit [Quit: No Ping reply in 180 seconds.]
Leopold has joined #riscv
clemens3 has joined #riscv
Armand has joined #riscv
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #riscv
ntwk has joined #riscv
junaid_ has quit [Remote host closed the connection]
<aurel32>
what is the best way to get the rdtime frequency? According to the specification "the execution environment should provide a means of determining the period of the real-time counter (seconds/tick)"
<sorear>
it's timebase-frequency in the dtb
<sorear>
if you mean in userspace ... not currently possible on linux, somebody needs to shepherd a patch to add it to hwprobe()
<sorear>
other supervisors may have more useful behavior
<jrtc27>
(FreeBSD has the kern.timecounter.tc."RISC-V Timecounter".frequency sysctl, though it's a bit ugly, and not sure it's really meant to be a stable interface)
<sorear>
or in the RHCT table in acpi i think
<jrtc27>
IIRC there was a way to get it from /sys?
<jrtc27>
(though probably similarly not a stable interface)
<sorear>
a semantically correct way that will also work on ACPI, or a raw mapping of the DTB data?
<sorear>
the current server-soc draft is cutting the knot by simply mandating that the rdtime frequency always be 1e8
<sorear>
*1e9
luca_ has joined #riscv
luca_ is now known as OwlWizard
naoki has joined #riscv
mlw has quit [Ping timeout: 260 seconds]
<gurki>
sorear: can you recommend a writeup regarding that server-soc?
<gurki>
i wonder where the peripherals are coming from
<aurel32>
yes, i meant for the userspace. The goal is to fix abseil broken with the rdcycle change. Upstream pointed me to that specification
OwlWizard has quit [Quit: OwlWizard]
Leopold has quit [Ping timeout: 260 seconds]
Leopold has joined #riscv
Leopold has quit [Ping timeout: 260 seconds]
Tenkawa has quit [Quit: Was I really ever here?]
Leopold has joined #riscv
jobol has quit [Quit: Leaving]
Tenkawa has joined #riscv
esv has quit [Remote host closed the connection]
EchelonX has quit [Quit: Leaving]
esv has joined #riscv
luca_ has joined #riscv
luca_ is now known as OwlWizard
crossdev has quit [Remote host closed the connection]
<gurki>
sorear: i was wondering whether the requirements in there actually match some dw ip or something or whether these were derived without looking at available ip cores
<gurki>
a lof of requirements in there will depend on "can i buy ip that can actually do this"
<gurki>
since - lets face it - only a quite little part of building such a soc is related to the isa itself
<sorear>
as I understand it it's intended to be "hardware expectations of rhel riscv64". it's only related to the isa insofar as distro install images are keyed by isa
<gurki>
ah so the rhel guys sat down and (probably with help) made a list of what they need from the software end of things?
<gurki>
that would make sense i guess
<sorear>
I don't know how much actual input they had into the process but davidlt has been endorsing the output
beber_ has quit [Quit: Gateway shutdown]
beber_ has joined #riscv
OwlWizard has quit [Quit: OwlWizard]
beber_ has quit [Quit: Gateway shutdown]
beber_ has joined #riscv
naoki has quit [Ping timeout: 264 seconds]
ldevulder has quit [Read error: Connection reset by peer]