xenos1984 has quit [Read error: Connection reset by peer]
gog has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
andreas303 has joined #osdev
nyah has quit [Ping timeout: 240 seconds]
knusbaum has quit [Ping timeout: 276 seconds]
heat has quit [Remote host closed the connection]
heat has joined #osdev
heat has quit [Ping timeout: 252 seconds]
knusbaum has joined #osdev
gamozo has quit [Changing host]
gamozo has joined #osdev
gamozo has quit [Quit: leaving]
gamozo has joined #osdev
gamozo has quit [Client Quit]
gamozo has joined #osdev
sonny has joined #osdev
sonny has left #osdev [#osdev]
orthoplex64 has quit [Ping timeout: 276 seconds]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dude12312414 has joined #osdev
hyenasky has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
sikkiladho has joined #osdev
sonny has joined #osdev
Likorn has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
<sikkiladho>
While going through AArch64 mmu guides, I came across this: https://developer.arm.com/documentation/101811/0102/Translation-granule, which defines size per entry based on the granule size. i.e for a 4KB granule, size per entry for Level 0 page table would be 512GB. How is this calculated?
<bslsk05>
developer.arm.com: Documentation – Arm Developer
<clever>
sikkiladho: an entry in the L0 table, points to a single page (4096 bytes i assume) of L1 entries
<clever>
and each entry in L1 points to a single page worth of L2 entries
<clever>
until you hit the deepest point (i forget)
<sikkiladho>
you can have 4-level tables, l0,l1,l2,l3
<clever>
so the size would then be ((pagesize / entrysize) ^ depth) * granule? i think
<bslsk05>
github.com: rpi-open-firmware/arm-mmu.txt at master · librerpi/rpi-open-firmware · GitHub
<clever>
so for arm32, the first level of the table is just an uint32_t[4096] (16kb), and each slot represents a 1mb chunk of the virtual space, covering the full 4gig of virtual space
hyenasky has quit [Quit: Client closed]
<clever>
and strangely, an L2 is only 1kb long, a uint32_t[256], with each slot representing a 4kb page
<clever>
and did i name L1 and L2 right in these notes??
<clever>
comparing that to the link you pasted...
<clever>
scrolling down a bit, they have an example of how a 48bit address is cut up into 5 parts, and each part is an index into a table
<clever>
the first part is bits 47:39, a 9bit int, so 512 slots in the L0, at 4k granules
<clever>
and with 64bit slots, uint64_t[512], thats 4096 bytes for the entire L0 table
<clever>
oh, wait
<clever>
> Math.pow(2,39)/1024/1024/1024
<clever>
512
<geist>
the way i think about it is you take the log2 of each size
<clever>
sikkiladho: the difference between slot0 and slot1 in the L0 table, is just +1 in bit 39 of the addr
<geist>
ie, 12 bits for 4K pages
<geist>
so the page tables then cover 12 + 9 + 9 + 9 + 9 bits of address space
<geist>
reason for 9 is each page table entry uses 8 bytes, so that shifts 3 off the log2
<geist>
okay this isn't clear, but once you grok it the math is simple
<geist>
[9][9][9][9][12] kinda
<geist>
so for 16k pages it's [11][11][11][11][14] and so on
<geist>
but that's basically where they get those 'bits used to index' from
<geist>
each level adds 9 more bits (for 4k base page granule)
<clever>
is my notes right, about arm32 only having L1 and L2?
<clever>
it feels weird now, that it doesnt start at L0
<geist>
unless you enable PSE
<geist>
i dont like they way they number things, but so it goes
<geist>
i generally prefer to number the root L0 and count down, and if you only have two level syou only get to L1, etc
<geist>
but they number them as if the terminal layer is always L3, i guess
<geist>
at least in that doc
<clever>
ah
<clever>
and yeah, i see similar in the aarch64 doc sikkiladho linked, with 64k granules, the L0 doesnt exist
<geist>
i think that's actually codified in the arch, because the ESR has a field that actually tells you waht level a permission check failed at
<geist>
so they had to define some numbering scheme
<clever>
is PSE like LPAE? supporting 64bit phys on 32bit virt?
<Mutabah>
Kinda iirc
<Mutabah>
I think it forces big pages and overloads bits 12-16 as extra address bits?
<clever>
oh, that would also be why i cant find it in the v7 docs
<clever>
because armv7 is pure 32bit
<geist>
oh LPAE, that's right. sorry
<geist>
got x86 mixed in there
<geist>
LPAE in arm == PAE in x86
<clever>
ahh
<Mutabah>
Is PSE also an ARM thing? I was describing x86's "PSE"
<geist>
armv7 has LPAE extensions, much like how x86-32 has PAE extensions
<geist>
ie, you only get 32bit of address space but a larger physical space, by increaseing each entry to 8 bytes and thus you now need 3 levels of page tables to fit it in, etc
<clever>
and LPAE is how raspi-os has gotten away with shipping a 32bit everything on devices with 8gig of ram
<geist>
right
<geist>
Mutabah: yah sorry, keep screwing up the names. PSE is iirc rarely used. was a temporary hack until PAE came along
<clever>
the pi4 also has 2 modes for peripheral io
<clever>
"high peripherals" mode puts the MMIO up at a 64bit only access, so you dont get a hole in your ram
<clever>
but now an aarch32 kernel cant touch MMIO until it enables LPAE
<clever>
so the default is "low peripherals" mode, which puts MMIO at the top of the 32bit addr space, creating a hole nearly dead-center in your 8gig of ram
<clever>
but now a 32bit kernel can touch MMIO before the MMU is on, and isnt forced to use LPAE
* geist
's head hurts with even more stupid rpi4 shit
<geist>
you're almost proud of how stupid that thing is aren't you?
the_lanetly_052 has joined #osdev
<clever>
its probably the stockholme, lol
<geist>
like 'hey look at this dumpster fire i keep warming me hands to! if you put truck tires in it vs regular car tires the smoke is pretty!'
<clever>
how would you have designed that?
<clever>
put a hole in ram? put all ram after mmio? screw 32bit?
<geist>
easy: put the peripherals at or around 0, start RAM at a higher address and cross right over 4GB
<geist>
that's how basically all modern SOCs do it now
<clever>
ah, yeah, thats simple enough
<clever>
i think the problem is that the rpi reset vector is 0, and they didnt want to fix that
<clever>
so ram must start at 0
<geist>
limits your mmio space to say a GB or so, but if you have a really fancy thing you probalby have PCI or whatnot, and you can put a second aperture > 4GB if you want
<geist>
easy: put a rom at 0, turn it off when you're done
<geist>
say 64MB of rom then peripherals, and you can start RAM at say 0x4000.0000 (1GB) and you have all that space
<clever>
pretty sure thats almost exactly what the amiga is doing
<geist>
that's precisely what the virt machine does
<clever>
the rom is aliased to 0 during reset, and once the bootrom is in control, it knows where the true copy lives in the addr space
<geist>
also iirc 68k has a high starting vector, i think
<geist>
so you could put your rom in the high part of the address. or maybe the other way? actually now that i think about it maybe nto
<clever>
from what i heard, the 68k loads a pair of uint32_t from addr 0 and 4
<clever>
and those become the initial SP and PC
<clever>
kinda sounds like cortex-m?
<clever>
the rom exists at some fixed higher addr, and is aliased to 0 temporarily, for that reset vector to find it
<geist>
yes cortex-m has the exact same thing
<clever>
but the initial PC is aware of that higher addr, and jumps directly to the non-aliased copy
<geist>
and i think those both came from VAX. iirc
<geist>
the double entry thing
<clever>
but ive also heard that the amiga bootstrap rom doesnt use the initial SP at all
<clever>
_start just loads sp like you would on any other platform, and that 32bit slot is instead used as some kind of version number
<geist>
yah cortex-m explicitly doesn't push anything on the reset vector since there's nothign to save
<geist>
and thus the SP doesn't really need to be valid. it's just a nice to have so your reset vector can be written in C
<clever>
so your free to ignore the initial SP
<clever>
yep
<clever>
i'm also thinking, about how i could modify the rpi, to behave less like a dumpster fire, lol
<clever>
on VC4 era, there is a dedicated mmu with 64 x 16mb pages, that translates "arm physical" to real ram
<clever>
so i could put some ram in the 1st 16mb slot, then 32mb of mmio, then 976mb of ram
<geist>
actually no VAX doesn't do the reset that way, so really the cortex-m in this case is basically copying 68k
<clever>
(that model range only supports 1gig max)
<clever>
and then treat that first 16mb of ram as a boot rom
<clever>
so the main block of ram begins at +48mb
<clever>
but with no ability to map things above the 1gig point in the physical space, the higher you move ram, the more you loose
<clever>
i need to figure out how the pi4 handles 8gig, and how i could coerce it into being more normal
<geist>
arm64 got no problem with that
<geist>
64bit and move on with things
<clever>
more, about how high/low peripheral works, and can i move it even lower, all the way to 0?
<geist>
get a better SOC?
<clever>
never! lol
GreaseMonkey has quit [Remote host closed the connection]
<geist>
moving physical stuff around is not really in your list of things you can do
<clever>
given that past models had a dedicated mmu and i could change the phys addr of mmio anywhere i want....
<clever>
it may still exist on the bcm2711
<clever>
i see signs that it does
<clever>
but it only has room for 1gig, same as before
vdamewood has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
vinleod has joined #osdev
vdamewood has quit [Ping timeout: 240 seconds]
vinleod is now known as vdamewood
<sikkiladho>
I think I finally got it. There are 4 tables in AArch64. L0,L1,L2 and L3. If we use 4KB granule, it means each entry in L3 can cover 4KB. There are 9(20:12) bits to L3 table index. Therefore, there are 2^9=512 slots. Whole L3 table can cover 512*4KB=2MB. L2 table can point to each L3 table. Therefore each entry in L2 can point 2MB and so on to L1 and L0. That's how it is calculated! Thank you.
Likorn has quit [Quit: WeeChat 3.4.1]
<geist>
yep!
<geist>
and then the math follows from there f you use non 4k page granultes
<geist>
everything is just shifted over
<clever>
-rwxr-xr-x 1 root root 1.1K Feb 8 09:09 /boot/overlays/highperi.dtbo
<clever>
oh, thats just cheating, lol
<clever>
when you tell the firmware to move the peripherals, in addition to moving them, it just applies this DT overlay
<clever>
and all its doing is patching the ranges= and dma-ranges= in a few spots
sonny has left #osdev [#osdev]
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<moon-child>
Q: what's the point of 5-level paging, or of arm's 52-bit address space extension?
<Mutabah>
More address space?
<moon-child>
yeah but why? What's it for?
<moon-child>
I can't imagine people are mmapping files at that scale...
<Mutabah>
Who doesn't wan't more AS? :)
<moon-child>
no but seriously what's the demand?
<Mutabah>
Probably future-proofing
<Mutabah>
so people can do massive memory-maps if needed
<moon-child>
yeah but again: why would you need that?
<bslsk05>
johnhartstudios.com: Sunday May 28, 2017 - B.C. Comic Strip
<geist>
moon-child: arm does not do 5 level paging
<geist>
x86 has a new 5 level paging extension, and it extends the aspace out to 57 bits
<geist>
the point of that is fairly obvious: 57 > 48 bits
<moon-child>
geist: yeah didn't mean to imply arm had 5lp. Hence the 'or' separating the two
<moon-child>
I mean 128 > 64 but no one is making 128-bit cpus...
<geist>
but yeah what use cases stuff has for that? I dunno, but i'm sure some folks do
aejsmith has quit [Remote host closed the connection]
aejsmith has joined #osdev
<Griwes>
48 bits is only 256 TiB, and with machines actually having TiBs of RAM per box and stuff like RDMA, that is... getting crammed, at least for HPC use cases
<moon-child>
oh yeah rdma
<moon-child>
mesh stuff
<moon-child>
makes sense
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
XgF has quit [Remote host closed the connection]
XgF has joined #osdev
archenoth has joined #osdev
Oshawott has quit [Ping timeout: 240 seconds]
toluene has quit [Ping timeout: 260 seconds]
toluene has joined #osdev
vdamewood has quit [Quit: Life beckons]
nick64 has joined #osdev
GeDaMo has joined #osdev
Likorn has joined #osdev
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
gog has joined #osdev
nyah has joined #osdev
kingoffrance has quit [Ping timeout: 240 seconds]
bauen1 has joined #osdev
pretty_dumm_guy has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
nick64 has quit [Quit: Connection closed for inactivity]
kingoffrance has joined #osdev
Dyskos has joined #osdev
<mrvn>
We have customers with TiB of ram at work. With 48 bit == 256 TiB half of that goes to user space, half to kernel. If you want a phys map for easy page table manipulations then that's half again. So 64TiB of ram before you ran into problems.
<mrvn>
Suddenly it's no so big an address space.
rorx has quit [Ping timeout: 246 seconds]
sikkiladho has quit [Quit: Connection closed for inactivity]
basil has quit [Ping timeout: 240 seconds]
nick64 has joined #osdev
Likorn has joined #osdev
<FireFly>
funky
heat has joined #osdev
rorx has joined #osdev
sonny has joined #osdev
basil has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 260 seconds]
mahmutov has joined #osdev
dude12312414 has joined #osdev
sonny has quit [Ping timeout: 252 seconds]
<mrvn>
grrr, why is there no std::span<T>::at(size_t index) that does range checking?
PapaFrog has joined #osdev
LostFrog has quit [Ping timeout: 240 seconds]
sonny has joined #osdev
<heat>
because c++ is, above all things, consistent
<mrvn>
heat: std::vector::[] has no check, std::vector::at() has check. How is that consistent with std::span?
<heat>
i r o n y
<heat>
;)
<GeDaMo>
"it's like bronzy or goldy but it's made of iron" :P
<mrvn>
Is class A { int x; } class B : A { int y; } still an aggregate class?
<bauen1>
mrvn: it is if you make all members and inheritance public
<mrvn>
godbolt comfirms that
puck has quit [Excess Flood]
puck has joined #osdev
<mrvn>
hehe, now isn't that a brilliant use of multithreading? std::thread t(func);
<mrvn>
t.join();
<heat>
it's just letting the main thread's cpu rest
<heat>
good programming if you ask me
<mrvn>
Assuming the thread isn't running on any core then t.join() could mark the thread to destruct itself and run the code in the main thread.
gog has quit [Ping timeout: 240 seconds]
sikkiladho has joined #osdev
<Griwes>
that'd be observable if you use tls
<mrvn>
Griwes: you would have to set the tls reg to the thread till the thread exits.
<geist>
true but why would you run it in the main thread? that would defeat the purpose
<Griwes>
mrvn, what if the main thread has already shared a pointer to, say, an atomic in its tls with other threads that would want to access it concurrently with the call to join?
<mrvn>
geist: save 2 context switches
<geist>
well sure, but the point is to have a thread. if you want some sort of coroutine thing then build it that way
<mrvn>
Griwes: then nothing. that keeps working
<Griwes>
wdym by "then nothing"?
<Griwes>
for the record, you cannot tell if that is the case by doing anything short of full program analysis
<mrvn>
Griwes: why should the address become invalid?
<Griwes>
ah, you mean swap the *tls* itself
<mrvn>
push and pop it
<Griwes>
I feel like that still has problems
<heat>
meaningless optimizations
<heat>
a totally non-trivial amount of work for a meaningless optimization
<mrvn>
but those are always such fun
<mrvn>
at least in the kernel the join() syscall can switch to the thread the code is waiting on for the remainder of the original threads timeslice.
<mrvn>
(or the threads if that is bigger)
<heat>
there's no join syscall
<heat>
it's a futex
<heat>
it just blocks
<heat>
on thread exit the futex gets woken up (it's set on thread spawning time)
<heat>
on linux that is, dunno about other OSes
<mrvn>
same thing there. If a futex blocks wake up the thread holding the futex with the remainer of the timeslice.
Likorn has quit [Quit: WeeChat 3.4.1]
Likorn has joined #osdev
sonny has quit [Quit: Client closed]
nick64 has quit [Quit: Connection closed for inactivity]
sebonirc has quit [Remote host closed the connection]
sebonirc has joined #osdev
sebonirc has quit [Remote host closed the connection]
sebonirc has joined #osdev
Dyskos has quit [Quit: Leaving]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
sonny has joined #osdev
sonny has left #osdev [#osdev]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
sikkiladho has quit [Quit: Connection closed for inactivity]
DanDan has quit [Ping timeout: 260 seconds]
DanDan has joined #osdev
vdamewood has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]