Noisytoot has quit [Remote host closed the connection]
Noisytoot has joined #riscv
BootLayer_ has joined #riscv
BootLayer has quit [Ping timeout: 258 seconds]
BootLayer__ has joined #riscv
BootLayer_ has quit [Ping timeout: 252 seconds]
BootLayer__ has quit [Ping timeout: 256 seconds]
BootLayer has joined #riscv
BootLayer_ has joined #riscv
danilogondolfo has quit [Quit: Leaving]
BootLayer has quit [Ping timeout: 245 seconds]
BootLayer has joined #riscv
BootLayer_ has quit [Ping timeout: 252 seconds]
BootLayer_ has joined #riscv
BootLayer__ has joined #riscv
BootLayer has quit [Ping timeout: 264 seconds]
BootLayer has joined #riscv
BootLayer_ has quit [Ping timeout: 258 seconds]
BootLayer__ has quit [Ping timeout: 258 seconds]
Stat_headcrabed has joined #riscv
ConorDooley is now known as conchuod
<conchuod>
palmer: those EXT_KEY() blocks in hwprobe_isa_ext0() could really do with some sorting, if you're finished merging stuff for 6.11..
<conchuod>
Should prob be sorted alphabetically so it's easy to find what's there and what's not.
<palmer>
I'd been trying to keep them sorted by value number
<conchuod>
I'm not sure that that really make sense in hwprobe_isa_ext0(), it does for the defines in the header.
<palmer>
OK, I don't have much of an opinion. Do you want to just send a patch to reorder them and see if people like it?
<palmer>
I can never remember the alphabet order, so it doesn't make a difference to me ;)
<conchuod>
kek
<ja_02>
lol
<conchuod>
maybe tomorrow when the current state makes it to linux next
<palmer>
ya, no rush
<conchuod>
All I'm gonna do is run :sort on it anyway, so no knowledge of the alphabet required palmer ;)
<palmer>
magic!
peeps[zen] has quit [Server closed connection]
peeps[zen] has joined #riscv
billchenchina- has quit [Ping timeout: 246 seconds]
nmeum has quit [Server closed connection]
nmeum has joined #riscv
theruran has joined #riscv
<clever>
i'm trying to dump a bootrom via /dev/mem under linux, and i think the PMP and opensbi are blocking it, but the domains opensbi listed, imply it should have full access, how would i debug further?
Stat_headcrabed has quit [Quit: Stat_headcrabed]
FL4SHK has quit [Server closed connection]
FL4SHK has joined #riscv
<heat>
soo.... i was reading up on the precise riscv semantics when modifying non-leaf PTEs... it's suggested in page 104 of the latest priv spec "If software modifies a non-leaf PTE, it should execute SFENCE.VMA with rs1=x0" [...]. But it's explicitly stated sfence.vma with rs1=<addr> also invalidates the page walker cache, so what gives?
ldevulder has quit [Quit: Leaving]
<heat>
i suppose that the desired semantics aren't to globally shootdown the TLB (with sfence.vma rs1=x0) on every non-leaf PTE write?
<sorear>
that sounds like a possible editing error but I'm not up to diggiing into the history right now
<sorear>
the last time I looked you did in fact need a very heavy-handed sfence after any change to non-leaf PTEs
<heat>
oh lord... really?
<heat>
maybe i'm not fully understanding what a "address-translation cache" (in riscv terms) entails... is it just the TLB, or does it encompass the page walker cache?
<jrtc27>
uh
<jrtc27>
reread the bullet point
<jrtc27>
it does not use the term page walker
<jrtc27>
and explicitly states that it's only for leaf entries
<jrtc27>
(the effects of the sfence.vma)
<sorear>
it's not like the situation ever comes up under linux ... non-leaf PTEs are written once when the corresponding page table is allocated and never touched again, so you don't need to flush except when an ASID is deallocated
<heat>
i'm aware it does not use the term page walker, nor does it use TLB
<heat>
(and to me its incredibly confusing)
<jrtc27>
"The fence also invalidates all address-translation cache entries that contain leaf page table entries corresponding to the virtual address in rs1"
<jrtc27>
that seems clear to me?
<heat>
sorear, afaik linux munmap does free page tables, at least on x86, et al
<sorear>
it made more sense in the first version when it was carefully phrased to not mention any specific kind of cache structure, only in terms of ordering of implicit accesses
<jrtc27>
and then people realise spatial locality is a thing and so you want to cache the intermediate non-leaf page table entries :)
<heat>
that sentence does not make sense to me, and the more i read it the less i understand it
<sorear>
there's no architectural guarantee of how quickly another core will walk page tables so you can't free a page table without an RCU-type process, regardless of the caching behavior
<heat>
why do address-translation cache entries contain leaf PTEs?? does this magic adress-translation cache encompass page translations only, does it encompass any possible walker cache, how does that work?
<jrtc27>
it encompasses whatever you want
<jrtc27>
as a designer
<jrtc27>
so long as anything that came from knowledge about the leaf PTE gets flushed
<jrtc27>
based on rs1
<heat>
ok so upper PTE "cache information" is not guaranteed to be flushed?
<jrtc27>
correct
<heat>
thanks
<heat>
does anyone know where this is handled in linux's case? particularly when adding page tables?
<JohnHenry>
do you mean PTE-flushing in general or the specific case of non-leaf PTEs?
<JohnHenry>
one reason address-translation caches might contain leaf PTEs is perhaps a design that caches them by-level and an upper level superpage i.e. (2M or 1G) is there
<heat>
specific case of non-leaf PTEs
<heat>
as far as i can see, it does not seem to be handled, but i might be looking at the wrong stuff
fuel has left #riscv [Leaving]
vagrantc has joined #riscv
BootLayer has quit [Quit: Leaving]
Starfoxxes has quit [Read error: Connection reset by peer]
<JohnHenry>
I suppose the thing to do is look for cases where non-leaf PMD/PGD/P4Es get altered? sorear just said there aren't any, so that might be it... I suppose if one ends up walking through old PMDs and end up faulting anyway it's kind of a wash
<JohnHenry>
seems slightly inefficient but not terrible
jobol has quit [Quit: Leaving]
zBeeble24 is now known as zBeelbe
zBeelbe is now known as zBeeble
drmpeg has quit [Ping timeout: 256 seconds]
drmpeg has joined #riscv
<JohnHenry>
heat: if you find a case, point it out to me?
<FL4SHK>
sorear: "openly developed dual issue" that's neat
<FL4SHK>
I'd like to develop an open source CPU that does OoOX at some point but that's coming after my current big project... which has my own instruction set, so I imagine it's off topic for this channel
FL4SHK is now known as FL4SHK
<FL4SHK>
I've done a bunch of the necessary software porting work for my ISA though
<FL4SHK>
I have a GNU Binutils port and a GCC backend
<FL4SHK>
actually, the RISC-V Binutils backend was rather helpful for writing mine
<FL4SHK>
haven't ported an OS yet but for my current project of just running baremetal code, the Binutils port is nearly complete