mwette has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
sevan has quit [Ping timeout: 255 seconds]
mlw has quit [Ping timeout: 252 seconds]
peepsalot has joined #riscv
epony has joined #riscv
crabbedhaloablut has quit []
epony has quit [Remote host closed the connection]
epony has joined #riscv
<drewfustini>
palmer: conchuod: who would be the right person to take this "[PATCH v7 1/4] riscv: defconfig: Enable mmc and dma drivers for T-Head TH1520"?
<palmer>
drewfustini: IDK. I usually take the defconfig stuff, but Conor takes the DTS updates. I just acked it, in case you guys want to keep it together
<palmer>
I'm also fine just taking that one, or the whole series, or whatever -- folks might be off for a bit...
<drewfustini>
Ok, it's not that important. It just occurred to me that I wasn't sure if it had been queued by anyone yet.
<drewfustini>
Thanks
JanC_ has joined #riscv
JanC is now known as Guest4332
Guest4332 has quit [Killed (tantalum.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
<palmer>
NP, this stuff is always kind of a grey area
esv has quit [Ping timeout: 268 seconds]
vagrantc has quit [Quit: leaving]
heat_ has quit [Ping timeout: 268 seconds]
notgull has quit [Ping timeout: 245 seconds]
notgull has joined #riscv
KombuchaKip has joined #riscv
KombuchaKip has quit [Quit: Leaving.]
KombuchaKip has joined #riscv
KombuchaKip has quit [Remote host closed the connection]
KombuchaKip has joined #riscv
mlw has joined #riscv
jacklsw has joined #riscv
andyc has joined #riscv
vigneshr has quit [Quit: Connection closed for inactivity]
Maylay has quit [Ping timeout: 252 seconds]
Maylay has joined #riscv
<geist>
reminds me i should look into trying to optimize qemu's riscv softmmu translation
<geist>
last i looked at it it was quite suboptimal, notably every invocation of sfence would just dump the entire TLB
jacklsw has quit [Ping timeout: 252 seconds]
KombuchaKip has quit [Quit: Leaving.]
mlw has quit [Ping timeout: 264 seconds]
KombuchaKip has joined #riscv
andor has joined #riscv
BootLayer has joined #riscv
andor has quit [Read error: Connection reset by peer]
mlw has joined #riscv
andyc has quit [Quit: Connection closed for inactivity]
mlw has quit [Ping timeout: 245 seconds]
esv has joined #riscv
epony has quit [Remote host closed the connection]
epony has joined #riscv
KombuchaKip has quit [Quit: Leaving.]
Amanieu has quit [Ping timeout: 255 seconds]
KombuchaKip has joined #riscv
unnick_ has joined #riscv
unnick has quit [Ping timeout: 256 seconds]
mlw has joined #riscv
Kyuvi has quit [Ping timeout: 250 seconds]
Kyuvi has joined #riscv
foton has quit [Ping timeout: 252 seconds]
foton has joined #riscv
notgull has quit [Ping timeout: 245 seconds]
Starfoxxes has quit [Ping timeout: 260 seconds]
notgull has joined #riscv
Starfoxxes has joined #riscv
mlw has quit [Ping timeout: 256 seconds]
<conchuod>
palmer: idm taking the defconfig stuff like that, its what they do in arm64 land.
<conchuod>
"it" being the platform maintainers take defconfig changes, not Will or Catalin.
<conchuod>
I didn't take the dts side of it cos I was not clear on whether there was going to be a resend.
<conchuod>
Oh, there was actually a v8 of that which I took the dts patches of. Palmer - you should take <20231206-th1520_mmc_dts-v8-1-69220e373e8f@baylibre.com>, I already sent the dts stuff to Arnd.
BootLayer has quit [Quit: Leaving]
cousteau has joined #riscv
Armand has joined #riscv
Armand has quit [Remote host closed the connection]
shamoe has quit [Quit: Connection closed for inactivity]
notgull has quit [Ping timeout: 256 seconds]
crabbedhaloablut has joined #riscv
notgull has joined #riscv
billchenchina has joined #riscv
billchenchina has quit [Remote host closed the connection]
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #riscv
psydroid has joined #riscv
shamoe has joined #riscv
jacklsw has joined #riscv
notgull has quit [Ping timeout: 256 seconds]
Stat_headcrabed has joined #riscv
Kyuvi has quit [Quit: Client closed]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Stat_headcrabed has joined #riscv
Armand has joined #riscv
<drewfustini>
Thanks, and sorry for linking to v7 when the final version was v8.
ntwk has joined #riscv
HumanG33k has joined #riscv
SpaceCoaster has quit [Quit: Bye]
SpaceCoaster has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Stat_headcrabed has joined #riscv
freakazoid332 has joined #riscv
jacklsw has quit [Remote host closed the connection]
frkzoid has quit [Ping timeout: 245 seconds]
<rbmarliere>
drewfustini: Hi, is mainline bootable for lpi4a ?
<rbmarliere>
I applied the eMMC patchset
BootLayer has joined #riscv
heat has joined #riscv
<drewfustini>
Mainline is bootable provided you build the initramfs into the kernel. 6.8 will have mmc. The driver patches are already in linux-next
Kyuvi has joined #riscv
jfsimon has quit [Read error: Connection reset by peer]
jfsimon1981 has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
bitoff has joined #riscv
<rbmarliere>
thanks!
iooi_ has joined #riscv
iooi has quit [Ping timeout: 255 seconds]
iooi_ is now known as iooi
sevan has joined #riscv
sevan has quit [Changing host]
sevan has joined #riscv
<unlord>
courmisch: I got a new canaan V1.1
epony has quit [Remote host closed the connection]
epony has joined #riscv
haritz has joined #riscv
haritz has quit [Changing host]
haritz has joined #riscv
felixonmars has quit [Remote host closed the connection]
ntwk has quit [Read error: Connection reset by peer]
Andre_Z has joined #riscv
bitoff has joined #riscv
BootLayer has quit [Quit: Leaving]
zjason` has joined #riscv
zjason has quit [Ping timeout: 245 seconds]
<palmer>
geist: a few people have looked into optimizing the TLB stuff, but I think nobody's actually finished
haritz has quit [Remote host closed the connection]
haritz has joined #riscv
haritz has quit [Changing host]
haritz has joined #riscv
Narrat has joined #riscv
[exa] has joined #riscv
[exa] has left #riscv [#riscv]
[exa] has joined #riscv
<[exa]>
hey all, quick question re paging: The RV privileged ISA (sec 4.3.1) says there are 2 ways to deal with dirty&accessed bits on page table entries (either it makes a page fault so that the OS can supply the A/D bit itself, or the hardware fills the bits by itself). How do I find out which one to use/expect? Or should my software be "ready" for both?
<dh`>
short answer is that if you want to be portable you need to cope with both, which is annoying
<dh`>
and which means in practice that the OS will do it and any effort the cpu makes to do that work is wasted
<[exa]>
like, there's a quite conservative way to implement a version that works well in both cases (basically one extra dirty/accessed check in pagefault handler), but yeah it would be better without that
<[exa]>
anyway is it really the case that there's no way to tell without trying this manually?
<geist>
what makes it particularly bad on risc-v is there's no separate trap for A bit faults, so the OS can't know why the PF happened and has to run a bunch of code for it
<geist>
it's a fairly major design flaw, IMO
<geist>
for the most part in practice most existing implementations do not fill in the A/D bits, so it's softwares job. possible the newer high end server chips will
<geist>
svade vs svadu in the isa string, if it's present
<[exa]>
like, you can very quickly see that the page in question is missing the A/D bit, right?
Andre_Z has quit [Quit: Leaving.]
<[exa]>
uuuuuuuh is the 'svade vs svadu' documented anywhere or so?
<geist>
only if you drill into the page table and see that it is
<geist>
thats in the riscv profile spec
<geist>
where it talks about RVA20 vs RVA22, etc. it calls out a bunc of additional features that go in the isa string for things like this
<[exa]>
oic
<[exa]>
good
<geist>
hmm i dont see where svadu is called out, but svade says that exceptions are thrown for A/D. note that if you're working with QEMU it by default handles A/D in hardware
<geist>
you can disable it with svade=1 on the cpu line, iirc
<geist>
palmer: kk, i thought so too re: the TLB bits in qemu. seems like a fairly large win there
Andre_Z has joined #riscv
<[exa]>
okay oh my
<[exa]>
thanks a lot!
<dh`>
the privileged architecture has a few design flaws yeah
<palmer>
geist: ya, I think there's some low hanging fruit. IIRC we just had an intern on it last time, and it didn't get finished
<geist>
kk, i might be able to carve some time on it for work (fuchsia at google) since we lean on it a lot
<geist>
didn't happen to throw the intern work over a fence anywhere on github or whatnot?
<geist>
at the moment we're having to run thousands of instances of TCG emulated riscv for testing, and it's painfully slow. until we get ahold of real server hardware, wink wink
<dh`>
realistically on a large machine scanning the pagetable for a/d bits that have been set is a lot more expensive than an occasional extra trap
<dh`>
so the whole idea should have been left off
<dh`>
since much as "16-32M RAM with an MMU" is a nice platform size for teaching, it's not useful in the real world
Andre_Z has quit [Quit: Leaving.]
<geist>
and if so then having a separate A trap is massively helpful. we have an issue in the fuchsia VM where we designed a fast path taht bypasses most of the upper VM for an access fault and dives directly into the page table to whack the A bit, bcause that's what ARM gives you
<geist>
alas, for riscv you have to go through a more expensive path to determine if it's an A fault :(
<geist>
and yeah taking the A/D fault up front is not bad from a VM point of view, it's just helpful when it's cheap
zkrx has joined #riscv
<muurkha>
dh`: won't it be more efficient if the CPU does updates the page table flag bits itself instead of trapping to the OS?
<muurkha>
I disagree with this idea that most machines are large machines. most computers have always been small computers, at least since the advent of the PDP-8. I think it's even true that small (<1024MiB) machines with an MMU outnumber larger machines with an MMU, although it's less obviously correct
<muurkha>
there tends to be a lot of segregation where people who program large machines aren't aware of the small ones
<geist>
muurkha: it is except that to make the bits useful the OS then has to scan the page tables, so getting a fault upon the edge transition of the state can in a certain sense be more efficient
<geist>
the more and more page tables there are the more work the OS has to do to scan them to find A/D bits, so there's a bit of a tradeoff
<geist>
one of the things that x86 does with its A/D bits that's nice is it *also* sets them in the intermediate page tables, which helps the scanner skip entire page table leaves as well
<geist>
neither riscv nor ARM does this, however, when setting their bits
<geist>
but... for example, if you're taking a manual A/D trap then you can set a virtual A/D bit in the intermediate tables in the RSV fields, thus emulating something x86 has
<geist>
and thus having your scanner be much more efficient at skipping entire trees
<geist>
so if you have your whole system optimized around taking A/D faults the worst problem with RISCV is all this said you *cant turn it off*
<geist>
there's no feature bit to disable automatic setting of the A/D stuff, so you *have* to deal with all versions of it
prabhakarlad has joined #riscv
<muurkha>
geist: sure, and scanning the page tables can be either more or less frequent than setting new A/D bits. it makes sense that sometimes you'd prefer a different policy than the one that's etched into the hardware
<geist>
yah
<muurkha>
I mean, correct me if I'm wrong (I'm often wrong!) but normally when you're scanning a page table in the OS it's because you're paging data in or out from/to the disk?
<muurkha>
I guess if you don't do that very often, you also don't have to set new A/D bits very often
<muurkha>
I haven't implemented a pager myself yet, so I could be overlooking something obvious
<geist>
generally you're doing it to get age or dirtiness data about the pages, so yes it depends on how aggressive you are