sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv | Matrix: #riscv:catircservices.org
ntwk has joined #riscv
<dh`> you scan the page table to read the a/d bits to update the page usage tracking you're doing
<dh`> that might be only when you're paging, but the more often you do it the higher-quality data you get out
<dh`> so, not necessarily.
<dh`> on the other hand, geist: if you don't want to deal with scanning the a/d bits you don't have to, it's sufficient to use the r/w bits to do it in software and then you just set a=r and d=w and nothing ever happens in hw
<geist> yep
<dh`> so there's no need to turn it off
<dh`> it's just a waste of silicon if present
<geist> yeah
<dh`> which probably means it will never be present in silicon but who knows
<dh`> that assumes that people doing the hw have access to os folks to tell them about these considerations
<dh`> which is mostly not true
<geist> but if it *is* present in hardware you have to jump through hoops to not use it
<geist> ie, a=r d=w
<geist> since you can't just turn it off
<dh`> that's not hoops, that's ignoring some extra bits that most machines don't have
<dh`> or at least, some machines don't have
<geist> well, except a and d bits *do* exist can you can use them
<geist> you get a bit more fidelity than just not having them and having to do a=r d=w
<dh`> not really
<heat> are you using D for anything in fuchsia?
<dh`> you get the same faults at the same time
<geist> heat: yeah
<geist> er, wait no
<heat> i know linux traps writes when tracking page dirtyness
vagrantc has joined #riscv
<geist> yah we do that
<geist> but we do use the A bit, and just emulate it on ARM with it disabled
<geist> and get the high level page table A bit feature, which is really nice
<dh`> that is, you get a fault on the first read and not the rest regardless
<dh`> higher-level page table A bits are only useful if you're scanning them...?
<geist> yes, which we do
<heat> if you're emulating the A bit, doesn't it make more sense to just skip the scanning?
<dh`> that's what I'd think
<heat> like just age the page right there and then
<geist> depends. you do more work up front, even if you eventually dont care about the page
<geist> ie, faults in and then you unmap it before it comes up
<dh`> that doesn't seem likely to happen often enough to chase after
<geist> what we generally do though is map new pages with A already set, then age them out by unsetting the A bit over time (the scan)
<geist> and then let them A fault back in. yes you could completely unmap the page, but if the A bit fault is fast (ie, free on x86) or cheap (on ARM) then it's less work that unmapping and then faulting the page back in entirely
<dh`> I guess, though since you don't need to do shootdown for that unmap it doesn't cost much
<dh`> (maybe you _should_ do shootdown, but the age data is only ever an approximation anyway)
<geist> well, key is we built it on the idea that the A fault is entirely at the 'low leve' of the VM, because it doesn't need to consulte the high level mapping structures
<dh`> certainly the shootdown doesn't need to be synchronous and that's the expensive part
<dh`> I think that's still true without an A bit
<dh`> (entirely at the low level)
<geist> well, sadly we didn't build it that way. so now we have to deal with it
<geist> anyway, so it goes. that's what they pay us for
<dh`> fair enough
epony has quit [Remote host closed the connection]
<dh`> anyway I wish I had found time to do the alternate privileged mode architecture early enough along that there was a point
epony has joined #riscv
<geist> wlel, i figure there's going to need to be at least one extension to the page tables as there will almost certainly be some sort of push for 16k pages or so
<geist> though i suppose that can be just easily done with another SATP mode
<dh`> yeah but doing a whole different supervisor mode? it's too late for that
<dh`> and it was too late when I first brought the point up some years back, too
<dh`> maybe if I'd started coming here earlier
<geist> though really a lot of it is being driven by companies now that they've kinda taken over the reigns
<geist> so unclear how much saying there matters at all
<dh`> ENOPARSE
<dh`> sorry, I'm missing something
<geist> hmm?
<geist> oh i just mean that seems most of the RISCV spec work *now* is really driven by the needs of the big companies that are getting onboard to make their chips
<geist> from what i follow internally at work
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.]
<dh`> right, that makes sense, just didn't follow the last sentence
<geist> oh s/there/here
<geist> you said coming here, as if what we say here really makes any difference. but i dunno, maybe i'm just wrong
<dh`> oh! typos like that can really be confusing :-|
<dh`> yeah, it's not that saying it here matters (much), it's that coming here and talking about it is what prompted me to get annoyed enough to seriously consider trying to do something about it
<dh`> not sure how much earlier would have been needed to get it taken seriously though
<geist> yeah
<dh`> also if I'd done it before spectre/meltdown I would have gotten it wrong; it was only that that persuaded me that mapping userland into the kernel address space is the wrong idea
<dh`> and embracing that makes it a lot easier for supervisor mode to be recursive and that makes all kinds of things simpler
<dh`> oh well
<dh`> if I ever get the risc36/windmill thing to happen it'll probably exhibit my ideas about traps and vm
<sorear> and the riscv profiles _do_ provide a feature bit for turning automatic setting of A/D bits off (rva20 and rva22 mandate A/D bits are never automatically set, rva23 will probably have https://github.com/riscv/riscv-svadu/blob/main/svadu.adoc which uses ADUE in menvcfg/henvcfg
vagrantc has quit [Quit: leaving]
<dh`> 2017 was evidently too late for that proposal
<dh`> and if anything proposing a whole different layout must come a lot earlier than an extension
heat has quit [Read error: Connection reset by peer]
heat_ has joined #riscv
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
stazthebox has joined #riscv
<muurkha> dh`: i think people are shipping alternative supervisor modes
<muurkha> (cocmpanies)
<muurkha> (companies)
heat_ is now known as heat
<dh`> oh? hmm
<muurkha> geist: what you say here makes a difference *to me*
<dh`> I can readily see lots of people coming to the same conclusions I have, but that seems like a lot of neck to stick out for the average company
<geist> sorear: excellent, of course though then SBI will probably just preset it to something and the supervisor mode OS still has to deal with it
<geist> but that's progress
<muurkha> Hellwig's proposal seems cogent
<muurkha> dh`: I was thinking of faster trap handling mechanisms than the standard
<muurkha> forr example
heat_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
<dh`> "extensions" and "alternative" seem like different things to me, but maybe they aren't compatible extensions
epony has quit [Remote host closed the connection]
<dh`> which reminds me, I had been under the impression that the standard trap vectoring setup only vectored interrupts, not exceptions, but I ran across code that seemed to be written for vectored exceptions
Leopold has quit [Ping timeout: 252 seconds]
epony has joined #riscv
Leopold has joined #riscv
<dh`> although it was hard to be sure, uncommented assembler writing scattered table entries by misusing .org is not the easiest thing to read
<dh`> (and I didn't have to care enough to sort it out myself)
epony has quit [Remote host closed the connection]
epony has joined #riscv
<muurkha> dh`: the particular risc-v chip I am thinking of, whose identity I unfortunately don't remember, doesn't implement the standard trap handling mechanism, just a fiq-like thing with iirc four hardware sets of shadow registers
<muurkha> to support four levels of recursive interrupt
<muurkha> so it isn't a compatible extension, but it's outside what most user code needs to worry about
epony has quit [Remote host closed the connection]
jbowen has quit [Excess Flood]
jbowen has joined #riscv
epony has joined #riscv
crabbedhaloablut has quit []
jmdaemon has joined #riscv
heat_ has quit [Remote host closed the connection]
heat has joined #riscv
<dh`> hmm
<dh`> that isn't really a _supervisor_ mode but w/e :-)
heat_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
Kyuvi has quit [Ping timeout: 250 seconds]
heat_ has quit [Ping timeout: 276 seconds]
heat has joined #riscv
agentcasey has quit [Ping timeout: 264 seconds]
heat has quit [Ping timeout: 240 seconds]
notgull has quit [Ping timeout: 240 seconds]
notgull has joined #riscv
notgull has quit [Ping timeout: 255 seconds]
notgull has joined #riscv
notgull has quit [Ping timeout: 264 seconds]
notgull has joined #riscv
BootLayer has joined #riscv
jacklsw has joined #riscv
shamoe has quit [Quit: Connection closed for inactivity]
mlw has joined #riscv
jljusten has quit [Ping timeout: 268 seconds]
jljusten has joined #riscv
jacklsw has quit [Remote host closed the connection]
Armand has joined #riscv
Armand has quit [Ping timeout: 255 seconds]
notgull has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #riscv
Kyuvi has joined #riscv
Andre_Z has joined #riscv
epony has quit [Remote host closed the connection]
epony has joined #riscv
Kyuvi has quit [Ping timeout: 250 seconds]
jmdaemon has quit [Ping timeout: 268 seconds]
Andre_Z has quit [Quit: Leaving.]
Leopold has quit [Ping timeout: 245 seconds]
Leopold has joined #riscv
kehvo has joined #riscv
Leopold_ has joined #riscv
Leopold has quit [Remote host closed the connection]
epony has quit [Remote host closed the connection]
epony has joined #riscv
bitoff has quit [Remote host closed the connection]
junaid_ has joined #riscv
bitoff has joined #riscv
epony has quit [Remote host closed the connection]
Stat_headcrabed has joined #riscv
epony has joined #riscv
junaid_ has quit [Remote host closed the connection]
Kyuvi has joined #riscv
JanC has quit [Ping timeout: 252 seconds]
JanC has joined #riscv
shamoe has joined #riscv
psydroid has joined #riscv
unnick_ has quit [Ping timeout: 276 seconds]
unnick has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
wingsorc has quit [Quit: Leaving]
heat has joined #riscv
kelvium has quit [Excess Flood]
Andre_Z has joined #riscv
tlwoerner has quit [Ping timeout: 256 seconds]
tlwoerner has joined #riscv
Andre_Z has quit [Quit: Leaving.]
tlwoerner_ has joined #riscv
tlwoerner has quit [Ping timeout: 276 seconds]
freakazoid332 has quit [Read error: Connection reset by peer]
frkazoid333 has joined #riscv
mlw has quit [Read error: Connection reset by peer]
mlw has joined #riscv
aurel32 has quit [Quit: leaving]
aurel32 has joined #riscv
Stat_headcrabed has joined #riscv
lagash has joined #riscv
unknown has quit [Ping timeout: 252 seconds]
foton has quit [Ping timeout: 246 seconds]
foton has joined #riscv
iooi has quit [Quit: iooi]
Trifton has quit [Quit: Client exited]
notgull has joined #riscv
mlw has quit [Ping timeout: 256 seconds]
jfsimon1981 is now known as jfsimon
Trifton has joined #riscv
ntwk has quit [Ping timeout: 256 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
ntwk has joined #riscv
epony has quit [Remote host closed the connection]
epony has joined #riscv
BootLayer has quit [Quit: Leaving]
vagrantc has joined #riscv
anotherYearEnds is now known as anotherNewYear
psydroid has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
junaid_ has joined #riscv
junaid_ has quit [Client Quit]
junaid_ has joined #riscv
junaid_ has quit [Client Quit]
jmdaemon has joined #riscv