linearcannon has quit [Read error: Connection reset by peer]
bradd has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 260 seconds]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 252 seconds]
gorgonical has joined #osdev
fedorafan has joined #osdev
<sham1>
We need glibc-\infty
bgs has joined #osdev
dza has quit [Quit: ]
gorgonical has quit [Quit: #optee]
small has joined #osdev
simpl_e has quit [Read error: Connection reset by peer]
simpl_e has joined #osdev
gorgonical has joined #osdev
<gorgonical>
god damn I hate working on these proprietary sbcs
<gorgonical>
why won't rockchip tell me what the fucking registers in sgrf do
bgs has quit [Remote host closed the connection]
<sham1>
Thus is working with proprietary stuff
<gorgonical>
I can't even figure out why op-tee even works in secure mode at this point
<gorgonical>
As in, in theory when you have DDR security regions and you set the SIF bit in SCR_EL3, secure code trying to access non-secure memory regions should create a fault
<gorgonical>
But op-tee doesn't mark the region of ram it seems to be running in until some part of the boot process
dza has joined #osdev
bradd has quit [Ping timeout: 268 seconds]
<geist>
ugh
<gorgonical>
indeed
<geist>
also ugh, looks like the device tree that is passed from opensbi into the kernel on riscv doesn't use the DTs reserve memory region mechanism
<geist>
guess that's just not what it does
<geist>
Heat had suggested using fdt_get_mem_rsv() but it returns nothing because the table is empty
<geist>
which i guess makes sense. it's not that descriptive, only address+size, whereas the more complex mechanism linux uses is actual tree nodes with more flexible metadata
<gorgonical>
I think my conclusion is that SCR_EL3.SIF refers to ifetch from pages marked NS=1. I can't find any elaboration at all, so I have to assume this bit doesn't magically propagate to all sorts of bus accesses
<gorgonical>
little kernel?
<geist>
yah
<geist>
already have code to parse the more complex memory reserve stuff, just thought i could remove that and use the simpler mechanism
<geist>
alas. no
<gorgonical>
dts supposed to have a reserved element in some place?
<gorgonical>
e.g. reserved for the bootloader?
<geist>
in this case yeah. the sbi firmware itself carves off a chunk of memory and marks it unavailable
<geist>
not unlike secure memory on ARM
<geist>
and marks it as such in a device tree section so the supervisor mode kernel doesn't touch it
<gorgonical>
that's typically the reserved-memory tree node, right
<geist>
SBI firmware running in machine mode is pretty similar to the PSCI firmware in EL3
<geist>
yeah
<geist>
heat had pointed out there's a simpler reserve memory thing in the DT structure itself that libfdt can walk for you, but alas it doesn't seem to be filled in
<gorgonical>
yeah I have familiarity with risc-v bootloaders and stuff. Not the internals of opensbi though
<gorgonical>
oh really, simpler?
<geist>
it's in the FDT header itself. just a pointer to an array of struct { address, size }
<geist>
where 0, 0 terminates the list
<geist>
seems to be outside of the tree itself
<gorgonical>
oh
<gorgonical>
weird
bradd has joined #osdev
<geist>
yah didn't know about this either until i traced the libfdt code
<bslsk05>
android.googlesource.com: lib/libfdt/fdt.h - kernel/lk - Git at Google
<gorgonical>
oh wow that's interesting
<geist>
yeah huh
<gorgonical>
I can only imagine it's not being filled in because of the ubiquity of reserved-memory
<gorgonical>
Because this way it's not only duplicated but not human readable either
<geist>
yeah my guess is the reserved-memory stuff is just more complex and powerful
<geist>
whether or not linux actually reads both formats and tries to union them i dunno
<gorgonical>
an exciting idea, that someone would feed you a dt with inconsistent headers and content
<geist>
heh 'exciting'
<gorgonical>
I wonder why they put it in there at all
<gorgonical>
isn't the whole point of the device tree that you can define sort of arbitrary nodes with syntax?
<gorgonical>
why force it into the header with a fixed, brittle syntax
<geist>
well, my guess is since it's in the header it goes way back to the beginning of OF
<geist>
probably late 80s
<geist>
so probably just way predates the reserve-memory stuff
<gorgonical>
i didn't realize dt was that old
<geist>
yah it came out of openfirmware from what i understand. is why it's big endian and whatnot
<geist>
first time i bumped into it was on old sun workstations and PPC macs
<gorgonical>
what exactly does flattened mean here
<gorgonical>
does it just mean that all the references and stuff are inlined and collapsed wherever possible?
small has quit [Ping timeout: 252 seconds]
<gorgonical>
it just occurred to me that I don't really know why it's called a flattened dt
<geist>
i think it just means the in memory format, 'flattened' into a binary run
<gorgonical>
oh yes maybe
small has joined #osdev
<moon-child>
everyone agrees you should be able to memcpy 0 bytes to a null or invalid pointer. But why shouldn't you be able to read/write 0 bytes from/to an invalid fd?
<Mutabah>
Well... a `NULL` pointer is UB to access, even with a zero-sized memcpy iirc?
<Mutabah>
wait... is it?
<moon-child>
I don't remember if it's UB, but I do think everyone agrees it _shouldn't_ be
<sham1>
The only reason I can imagine is that the kernel does something silly like CurrentProcess()->GetFileDescriptors()[fildes]->Read(/*params*/)
<sakasama>
I don't agree. It should just be invalid.
<Mutabah>
I don't see a disparity, because the two are different concepts
<Mutabah>
a memcpy is a copy from a region of memory - an empty region has a size of zero, so the copy is valid
<Mutabah>
but a `fd` is a stream handle - there isn't (usually) a separately known size
<Mutabah>
thus, any attempt to use an invalid FD should fail - because doing so is a bug
<Mutabah>
(or indicates a bug)
<moon-child>
you might argue by the same token that any attempt to use a null or invalid pointer also indicates a bug
<moon-child>
(though a pointer to one past the end of a valid allocation should be fine for a zero-sized memcpy, obviously)
<Mutabah>
for null, I would
<Mutabah>
(as null is a common sentinel for "invalid")
<Mutabah>
But for a properly-aligned nonzero but invalid pointer, it can be considered to be the one-past-end pointer of an empty range
<moon-child>
it can't
<moon-child>
but null might be what you use for the pointer in an actually empty array
<Mutabah>
Worth noting: My rustacean is showing - a null pointer is never a valid value for a safe pointer to have, but `1` is valid (for a pointer to a byte aligned zero-sized type)
<moon-child>
we are in c-land :)
<Mutabah>
We're talking opinions
<moon-child>
I think david chisnall explained to me at some point why a random pointer can't count as a pointer to one past the end of a zero-sized allocation in c, but can't find it now
<moon-child>
lobsters search is really useless
gorgonical has quit [Remote host closed the connection]
danilogondolfo has joined #osdev
slidercrank has joined #osdev
gog has joined #osdev
<mrvn>
moon-child: you can not write 0 bytes to a pointer. that's UB.
<mrvn>
moon-child: for latest standards a memcpy(nullptr, nullptr, 0); is a type error I would say.
<mrvn>
As for read/write of 0 bytes to an FD I would assume the access check to the FD is done before checking the size. Reading 0 bytes from an FD I think also has meaning. Shouldn't it block till there is data ready to read from a socket or pipe?
x8dcc has joined #osdev
gildasio2 has quit [Remote host closed the connection]
<mrvn>
moon-child: Note: pointers can be tagged by the hardware so you can't even form a pointer that isn't pointing at a valid object (AS400 has something like that). So just casting a random int to pointer would throw a cpu exception.
gog has quit [Quit: byee]
<mrvn>
ARM can tag pointers too, if supported, but I don't know how serious the cpu takes those.
gog has joined #osdev
<klange>
Enforcement can be enabled by a flag.
<klange>
But it's kinda complicated, I think it's more common to just set the "ignore top byte" flag and have, eg., free() slap you if you give it an untagged pointer
<mrvn>
klange: but that would be when you use a register as a pointer. Just loading the value into a register does nothing.
<mrvn>
klange: or does lea fault then too?
gildasio2 has joined #osdev
<klange>
I do not believe anything not actually going through the MMU can trap for tagging, so only a dereference / use as a memory operand would do so.
<klange>
But the ARMARM is hot garbage, so I can't easily check individual instructions.
<gog>
nya
<mrvn>
klange: it would break pretty much every program since compilers use lea a lot to load integers and not just pointers.
<mrvn>
so I'm pretty sure lea won't fault.
Vercas has quit [Ping timeout: 255 seconds]
<klange>
C23 got rid of a lot of verbiage around trap representations; I think outside of floating point values, the intention is that having what is now called a "non-value representation" exist is not itself something that should trap or be undefined behavior?
<mrvn>
did C23 also get rid of one's-complement integers or is that only c++?
<klange>
Strictly speaking C simply did not specify, but now it's two's-complement only.
<mrvn>
signed overflow being undefined pretty much spelled it out that integers could be one's-complement, two's-complement, sign+magnitude or whatever.
<mrvn>
What annoys me a bit is that c++ still says integer overflow is UB while with two's-complement being required it's now perfectly defined.
<klange>
It's possible that the C++ UB is accounting for some possibility that signed integers have special interpretation and overflow traps while that's not permitted for unsigned? But it is probably just a holdover from C.
GeDaMo has joined #osdev
<mrvn>
klange: no, they have to be two's-complement now. My guess is that they didn't want to break compiler optimnizations. Knowing there is no overflow allows loops to be simplified a bunch.
Celelibi has quit [Ping timeout: 248 seconds]
<mrvn>
and you don't have to truncate results to int all the time.
<mrvn>
.oO(you are right on the overflow traps though, that remains too)
<moon-child>
'''optimizations'''
<moon-child>
such bullshit
<moon-child>
it literally makes no actual difference
<moon-child>
and everyone else gets shafted with cves for it
<mrvn>
moon-child: and yet you get different (slower) code when you make your loop with an unsigned.
<Griwes>
there's measurable difference between codegen for integers and unsigned integers
<Griwes>
there's multiple talks about this on youtube
nyah has joined #osdev
<froggey>
stop using c/c++
<mrvn>
that's what the NSA tells us
<mrvn>
cpp2 has some nice changes, maybe I should be using that.
<ddevault>
I'm going to print out the ACPI standard and self-immolate in front of Microsoft headquarters with it held in my lap
<moon-child>
Griwes: no one has shown me a real workload which gets appreciably slower with -fwrapv
<moon-child>
people handwave at asm snippets, which have fuck all to do with anything
<mrvn>
moon-child: "This flag enables some optimizations and disables others."
<mrvn>
moon-child: and who says that has any effect on the optimizations that work because the compiler can assume there is no overflow?
<moon-child>
the whole point of -fwrapv is to make the compiler assume that things can overflow
<sakasama>
ddevault: They'll just toss you in with the others in their catacombs.
<moon-child>
somebody once pointed me at a chandler carruth talk where he says 'such-and-such tight loop in bzip2 is slow because it uses unsigned instead of signed'. So I humoured them; checked out bzip2, compiled with the relevant bits replaced with signed, and the performance was exactly the same
<moon-child>
actually, the loop was super slow, but not because of signed vs unsigned :)
<mrvn>
moon-child: the description sounds more like telling the compiler that integers are two's-complement. Which would be default in the latest standard anyway.
<sham1>
People should stop relying on these pieces of undefined behaviour, damn it
<moon-child>
that's literally all it does. Can substitute -fon-strict-overflow if you like
<sham1>
As for 2s complement being default, yeah, it means that there is only thing that you get out of INT_MAX+1, which is a proper value, but there are certain invariants that still break
<sham1>
For example, x < X+1
<moon-child>
two's-complement is the only _representation_, but _behaviour_ on overflow is still undefined in the latest c (and I assume c++) spec
<mrvn>
moon-child: also note that the signed and unsigned code might very well run at the same speed because the cpus are optimized on a hardware level. You might just increase the utilization of the cpu and not run faster or slower.
<moon-child>
yes, that's (part of) the point
<moon-child>
the other is that the function was super slow for reasons that had nothing to do with signed/unsigned, and if you made it fast, it would be fast regardless of signed/unsigned
<mrvn>
moon-child: that flag does more. And those changes will have ripple effects.
<sham1>
Related to the point of not relying on UB, quit writing non-char words onto unaligned addresses, damnit
<moon-child>
show me the benchmarks
<mrvn>
moon-child: I'm not talking about speed. I'm talking about behavior.
<moon-child>
I don't follow
<moon-child>
-fwrapv defines behaviour which was otherwise undefined
<mrvn>
moon-child: see how you get different code for signed and unsigned
dutch has joined #osdev
<moon-child>
your point being?
<mrvn>
that was my point
<moon-child>
signed and unsigned integers are different. You also get different code for 'x < y' for signed vs unsigned x and y
<moon-child>
so what?
<mrvn>
They didn't remove that signed overflow is UB because (a) the traps you mentioned and b) it would change the codegen a lot and break existing code (even it that code is bad)
<moon-child>
what???
<moon-child>
defining behaviour which was previously undefined can't be a breaking change
<mrvn>
moon-child: lol. Do you have any idea how much code in the wild depends on behavior that's strictly speaking undefined?
<sham1>
Too muxh
<mrvn>
way way way too much
<moon-child>
this is not that sort of thing though
<sham1>
But they shouldn't rely on it. That's the entire point of it being undefined
<moon-child>
I mean, *(double*)&some_int, fine
<moon-child>
but the only behaviour you could possibly be reasonably relying on with signed overflow is wraparound
<moon-child>
esp. as anything else will break when you compile without opts
<mrvn>
anway, there are cpus out there that trap on signed integer overflow so the rest of the argument is moot.
<moon-child>
they might support a 'signed add' instruction that does that
<mrvn>
unless you want to write the specs as "signed integer will overflow like two's-complement does except where hardware will trap on it"
<moon-child>
but 'unsigned add' is literally the same function, and has to be supported and can't trap
<moon-child>
so you can just use that
<mrvn>
not so easy for mul
kof123 has quit [Ping timeout: 268 seconds]
<moon-child>
low mul is the same for signed/unsigned
<moon-child>
it's just the high part that's different
<moon-child>
and c doesn't have high multiply. When you do have a widening multiply, though--it can't overflow; you get the full product
Left_Turn has joined #osdev
<mrvn>
C only has high multiply. an no widening
<moon-child>
no
<moon-child>
c has low multiply
<mrvn>
signed * signed = signed
<moon-child>
the high multiply of (say) two 64-bit integers is mathematically floor(x*y / 2^64)
<ddevault>
I'm going to print out hard copies of the ACPI spec and start showing up RISC-V events to ritually burn it on the lawn outside of the conference
<moon-child>
mrvn: yes; that's the same for signed/unsigned
<mrvn>
moon-child: then your statement is just wrong. the low multiply is different for signed.
<mrvn>
it multiplies the absolute value of the integer and then puts the sign back.
Turn_Left has quit [Ping timeout: 252 seconds]
<moon-child>
mrvn: find me an example of a case where, given uint32_t x, y, x*y is different from (uint32_t)((int32_t)x*(int32_t)y)
<mrvn>
moon-child: x = MAX_INT + 1;
<mrvn>
the second code is simply undefined
elastic_dog has quit [Read error: Connection reset by peer]
<moon-child>
mrvn
elastic_dog has joined #osdev
kof123 has joined #osdev
<moon-child>
the _whole point_ of all this is that if we make signed overflow well-defined, we can implement basic signed arithmetic ops as unsigned arithmetic ops to get around trapping on cpus that do that
<moon-child>
division is the one exception, but that only 'overflows' for INT_MIN/-1. And is slow so it's easy enough to check for it
<moon-child>
oops I forgot to compile with -fwrapv. Same result though
<moon-child>
mrvn: explain my result, then
<mrvn>
ups, my error, -1 * -1 = 1 obviously.
<moon-child>
:)
<moon-child>
you'll find you get the same result in all cases
fedorafan has quit [Ping timeout: 248 seconds]
<mrvn>
moon-child: uint32_t * int32_t?
<moon-child>
I would expect the uint gets promoted to an int before doing the multiply
<mrvn>
nope, can't promote to a "smaller" type
<moon-child>
idk, I never had the promotion rules straight
<mrvn>
they are a mess
<moon-child>
but my recollection is it has to promote them to some common type and then do the multiplication there
<moon-child>
indeed
<mrvn>
can't find a case where the bits after mul are different but the flags certainly are.
<moon-child>
good thing c doesn't have flags
<sham1>
moon-child: slight correction, multiplication would be X*Y mod 2^64
<mrvn>
sham1: obviously, or 2^32 in this case of uint32_t
<sakasama>
From the LLVM docs for 'mul': "Because LLVM integers use a two’s complement representation, and the result is the same width as the operands, this instruction returns the correct result for both signed and unsigned integers. If a full product (e.g. i32 * i32 -> i64) is needed, the operands should be sign-extended or zero-extended as appropriate to the width of the full product."
<moon-child>
sham1: the _high_ multiply
<sham1>
There's no divide semantic there. Instead you're on the modular ring just doing modular ring things
<moon-child>
low multiply is mod, yes
<sham1>
But there's no high multiply in C tho
<sham1>
At least not standard
<sham1>
The low multiply is the only multiply
<mrvn>
moon-child: the flags become relevant when you have if (x * y < 0)
<moon-child>
that's what I _said_
<moon-child>
ffs
<sham1>
Hm, must be not enough caffine
<mrvn>
But what that means on an overflow .... hard to say
<moon-child>
mrvn: nope
<moon-child>
x*y < 0 will be true if the high bit of the _low_ product is 1
<moon-child>
but that might not be the same as the sign bit of the true product
<mrvn>
moon-child: no. it will be true when the negative flag is set. Which makes no sense for unsigned mul.
fedorafan has joined #osdev
<mrvn>
moon-child: with mulu instead of muls the compiler has to add code to test the sign bit
<moon-child>
sure, if you have one
<sakasama>
The sign matters for div/rem, but not the other basic arithmetic operations.
<moon-child>
ANYWAY
<moon-child>
the point is that there's no reason not to make signed overflow well defined in c
<mrvn>
moon-child: and now you have optimization problems. if the compiler knows x and y are positive it still has to test because suddenly the code can overflow into negative numbers and behave differently.
<moon-child>
show me the benchmarks
<mrvn>
this has nothing to do with speed
<moon-child>
what optimisation problems are there, then?
<mrvn>
the one I describved
<moon-child>
please describe concretely the problem, because it's not clear to me
<mrvn>
moon-child: bool f(unsigned x, unsigned y) { int sx = x; int sy = y; return sx * sy < 0; }
<mrvn>
make that uint16_t x to avoid the UB on cast
<moon-child>
and?
<mrvn>
That function is guaranteed to return false for all valid inputs and your change makes it so it has to actually compute the value and may return true
<mrvn>
It can no longer be optimized out.
<moon-child>
it is defined for more inputs. That is not a compatibility break
<moon-child>
the behaviour on the inputs for which it was previously defined is exactly the same
Celelibi has joined #osdev
<mrvn>
moon-child: but your change the amount of inputs that are defined.
<mrvn>
and yes, there is code out there that relies on that UB.
<moon-child>
show me this code
xenos1984 has quit [Read error: Connection reset by peer]
<moon-child>
also: that is the sort of behaviour which exhibits non-locality; which varies according to compiler switches; which varies according to compiler and compiler version
<moon-child>
it is not the purview of the language standard to maintain compatibility with such code
<mrvn>
no argument there
<moon-child>
c23 had explicit compatibility breaks (and it was fucking stupid, but)
<mrvn>
unfortunately such code is way way way to common
<moon-child>
so what is your argument?
<mrvn>
same as all this time. they didn't want to break stuff too much (and they couldn't anway due to the cpus that trap on overflow and code that relies on those traps)
xenos1984 has joined #osdev
<mrvn>
moon-child: apropo integer promotion being insane: uint16_t f(uint16_t x, uint16_t y) { return x * y; } is UB for a half of it's inputs.
SGautam has joined #osdev
xenos1984 has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
<SGautam>
Why does the magnitude of the fourier transform of e^-x look like a normal distribution?
<SGautam>
Ooops wrong channel
<mrvn>
SGautam: you mean half a normal distribution?
<mrvn>
\_
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #osdev
x8dcc has quit [Quit: leaving]
foudfou has quit [Quit: Bye]
foudfou has joined #osdev
[itchyjunk] has joined #osdev
joe9 has quit [Quit: leaving]
joe9 has joined #osdev
gildasio2 has quit [Remote host closed the connection]
papaya has joined #osdev
heat has joined #osdev
<heat>
geist, aw the riscv mem rsv thing you added is different?
<heat>
sucks
small has quit [Ping timeout: 252 seconds]
gildasio has joined #osdev
dutch has quit [Ping timeout: 246 seconds]
<Jari--_>
BIOS is stuck on this machine
<Jari--_>
Windows 11 works
<Jari--_>
cant install Ubuntu for development
<GeDaMo>
Something to do with SecureBoot?
<heat>
thank your firmware
<heat>
whatever keeps you as far away from linux as possible
<heat>
i wish my firmware was broken as well smh
<kof123>
"I'm going to print out the ACPI standard and self-immolate in front of Microsoft headquarters with it held in my lap" "They'll just toss you in with the others in their catacombs." is there a bios/uefi pile?
<zid>
my garlic naans are too hot to eat with my fingers :9
<GeDaMo>
What about your toes? :|
<zid>
osdev me a new garlic naan firmware heat
<sham1>
Don't you mean NaNs
* sham1
plays laugh track
* gog
claps
<zid>
is a naan an snan or nan?
<gog>
i disable secure boot because what's the point
<gog>
if somebody gains access to my machine and installs an unauthorized boot thing good on them
<zid>
yea that's what I told heat
<zid>
blew his mind
<sham1>
gog: nooo, but now someone could tamper with your bootloader in an Evil Maid attack, noook
<zid>
I directed him to the xkcd comic about printer drivers vs my email account
<sham1>
Also, can we just acknowledge that "evil maid attack" is both an unfortunate name for a security threat and also a great band name
<zid>
evil made attack is my new light novel series
<gog>
pretty sure the cleaning lady here knows we're not worth tampering with
<sham1>
The name's not long enough
<gog>
she sees the shit we get up to and knows we're a half-assed outfit
<gog>
we have nothing
<zid>
we're even half assed?
<gog>
i mean
<gog>
at best
<kof123>
well, evil maid will plant a backdoor rather than just pawn your stuff, yeah......
<zid>
It feels at *best* like a treehouse with a "no noobs" sign outside
<kof123>
this too is like the xkcd $5 wrench password extractor
<gog>
yeah it'd be more profitable to stea and fencel the shit we have in unlocked cabinets and don't evne use
<zid>
sham1: The story of the evil maids who want to wipe out humanity - Attack on dust
<sham1>
Nice
<heat>
if you replace the n in "no noobs" with b you get "bo boobs"
<heat>
which is a hell of a lot funnier
<gog>
booba
<heat>
bobs
<zid>
heat has boobs though
<heat>
mammal moment
<zid>
cringe r.r. heat
Burgundy has joined #osdev
slidercrank has quit [Ping timeout: 268 seconds]
dutch has joined #osdev
janemba has quit [Ping timeout: 252 seconds]
<Jari--_>
zid: heat a girl?
<heat>
no
janemba has joined #osdev
<heat>
girls are not allowed in the osdev treehouse
<heat>
because they are weird and eat boogers
<zid>
heat has boobs cus he's addicted to watching sports
<zid>
geist: time to dig out your A750, big driver update apparently
pg12 has quit [Ping timeout: 255 seconds]
pg12 has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
<marshmallow>
how would you proceed if you were to perf a C++ program? like, finding out if I'm using the correct data structures, if there is any kind of bottleneck..
<marshmallow>
could time(1) help here?
<heat>
use perf
<heat>
:))
<SGautam>
marshmallow: valgrind, although that's mostly for profiling purposes and finding leaks. I don't think we'll have optimizeGPT for a long time judging from ChatGPT performance on coding.
<marshmallow>
OK perf is a powerful tool, and no doubt it would help here. but say we'd like to give time(1) a try. how could I make sure I'm not taking advantage of cache hits during the subsequent run of the program?
<heat>
you don't
<heat>
... because time is not a profiling tool
<heat>
time can give you a HINT (run your prog with large input, 10s, change your prog to be fast, run, 5s)
<marshmallow>
now I actually wonder how perf can actually get something useful out of billion of instructions executed per second
<zid>
driver overhead seems cut down on the intel driver at least, +77% fps in cs:go et
<heat>
marshmallow, because it samples your code with a timer and can effectively use CPU performance monitoring counters
<marshmallow>
heat, but if it samples then it might likely miss some instructions or some functions that could be more or less interesting, no?
xenos1984 has joined #osdev
<heat>
yes, which is why you sample often and run it for a good bit of time
<zid>
heat disregard oprofile, acqurie ds
<heat>
zid zid
<zid>
heat hat
<zid>
het heet heat haat hat
<heat>
u good ad palying video game dark soul or not yet?
<zid>
I am okay
<marshmallow>
heat: so perf itself runs the program multiple times or you need to run it under perf more times?
<heat>
you run it once and make it do something for a good bit of time. the more time it takes, the more accurate data is
<heat>
with intel-pt you get the accuratest of data since it does not sample I believe (or it samples with a stupidly high freq timer, not sure)
bgs has joined #osdev
Burgundy has quit [Remote host closed the connection]
gareppa has joined #osdev
<marshmallow>
heat: could in principle a simple x86-64 rdtsc be used here?
<heat>
rdtsc of what?
gareppa has quit [Remote host closed the connection]
<marshmallow>
sorry, rdtsc at function prologue and epilogue to measure the execution time of a function
terminalpusher has joined #osdev
<heat>
yes? but that will affect the results
<heat>
why are you trying to half-ass profiling?
<heat>
you asked "how would you proceed?" and I said "use proper tooling (perf)" and now you want to stick rdtsc in functions or use time(1)
<gog>
proper tooling?
<gog>
breh this is osdev
gog has quit [Quit: Konversation terminated!]
<marshmallow>
heat: yeah sorry, was just freaking out :P
dude12312414 has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
xenos1984 has joined #osdev
hmmmm has quit [Remote host closed the connection]
hmmmm has joined #osdev
smach has joined #osdev
smach has quit [Client Quit]
gorgonical has joined #osdev
gog has joined #osdev
xenos1984 has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
heat has quit [Ping timeout: 252 seconds]
slidercrank has joined #osdev
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
demindiro has joined #osdev
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<gorgonical>
what's everyone doing this first day of february
<gog>
trying to figure out why drawing bitmap fail
<mjg>
first day of slacking this month
<gog>
the short answer is idk yet
<mjg>
got a 31 day streak last month
<geist>
more workin
<gorgonical>
I'm recovering from the shellshock of finding out that yet again arm64 manufacturers hate me
<gorgonical>
any arm64 experts mind cluing me in on exactly what SCR_EL3.SIF does? The description is "forbids ifetch from non-secure memory when in secure state" but that's a little vague
<geist>
which part? the ifetch part?
<geist>
probably means 'no instructions can be run from non secure memory' which seems like another safety/security bit
<gorgonical>
mostly what is meant by "non-secure memory"
<geist>
lots of those going in
<gorgonical>
As far as I can tell it must refer to the NS bit in the page tables
<geist>
almost certainly
<gorgonical>
There's so many confusing interlocking hardware components of trustzone that it's not very easy to tell what bits affect what
<gorgonical>
the secure/non-secure state of the PE is taken into account for DRAM bus accesses but seemingly not this SIF bit
* geist
nods
<gorgonical>
and based on my understanding it has to be that way because op-tee for example doesn't even configure its memory as secure so SIF can't be doing that
<gorgonical>
anyway, I digress
bgs has quit [Remote host closed the connection]
<demindiro>
I'm trying to update my Rust cross compiler to the latest version
<demindiro>
Took me a while to figure out why it supposedly couldn't find compiler_builtins
<demindiro>
And also always fun when a bunch of APIs get changed
<geist>
eep, what version to what? was it a major jump?
<demindiro>
idk what the last version I used was, but there are ~20000 new commits apparently
<geist>
ah from source. got it
<geist>
i stopped building from source once i discovered rustup
<demindiro>
You kinda need to build from source if you want to port stdlib
<geist>
good to know yeah
heat has joined #osdev
<geist>
and then theres heat
<heat>
and then theres geist
* geist
shakes head, sadly
<geist>
heat heat heat when are you ever gonna learn
<heat>
learnw aht
<geist>
exactly.
<heat>
damn
<geist>
here's my masochistic mission for the day: build qemu on ubuntu-riscv64 on top of qemu
<heat>
build qemu under tcg?
<heat>
or qemu under kvm?
<geist>
though really it's not *too* bad. riscv on qemu tcg on a ryzen 3950x seems to be approx 500mhz ARM class
<geist>
so it's pretty good all things considered
<heat>
i mean, fuck
<geist>
haha under kvm. tat's funny heat
<heat>
that is not that good
<geist>
yah but whe yu think about it it's about right: about a 5-8x slowdown because TCG
<heat>
my rpi zero 2 w struggles to compile e.g gn, which isn't that large
<heat>
iirc it even OOMs (and it has 512MB of ram)
<mjg>
what's tcg?
<geist>
at least in the case of the qemu instance i can add tons of cores and lots of ram so that's not an issue
<heat>
qemu software thing
<geist>
'tiny code generator' i think is the full name
<heat>
geist, is a 128T threadripper the fastest riscv CPU? :v
<heat>
oh yeah Intel cancelled their riscv project!
<geist>
well interestingly, on a high end x86 core on qemu tcg it's pretty close if not exceeds the speed of a sifive unleashed board
<geist>
which also benchmarked around an 800mhz arm or so, according to my informal benchmarks
<geist>
and in qemu you can get much better io throughput
<demindiro>
I imagine it's a fair bit less power efficient though
<geist>
indeed
<geist>
also my guess is there are things that benchmark terribly, probably lots of context switches where TCG would conceivably throw away jitted stuff and start over
<geist>
i honestly dunno how effective TCG jit caches are
<heat>
ugh
<heat>
riscv sucks
<geist>
it's more of a 'reset of expectations'
<geist>
there was a time when this was a fast and efficient machine, it was just some time ago
<geist>
it's like modern retrocomputing
<gorgonical>
heat: no u
<heat>
i still dont understand why the damn vendors dont just get something fast
<geist>
they are. it's just taking a while to catch up. basically think of riscv socs as reset back about 10 years in ARM world
<geist>
but the slope of performance is fairly high, so it's catching up to the status quo
<geist>
just needs another 5 years or so
<mrvn>
can't make it fast, stupid patents.
<geist>
nah it's just money and the bootstrapping effect. one cannot simply bust out a high end core from scratch, you have to go through some iterations, build a team, etc
<geist>
and find a market, so takes some number of years to bootstrap it
<heat>
but in theory couldn't an arm vendor just take out the ARM frontend for the RISCV one and call it a day?
<geist>
only vendor that could do that is something like apple
<geist>
maybe they will
<heat>
why?
<geist>
why what?
<heat>
why only apple?
<geist>
because they build their own designs
<geist>
if you are licensing arm cores, like most other vendors, they can't modify it
<heat>
really?
<heat>
so what does i.e qualcomm do?
<geist>
that's a good question. perhaps they'll make th emove on RV first
<geist>
or something like samsung
<geist>
would need to be a big company that otherwise has expertise to build high end cores decide to switch
<heat>
seriously now im worried wtf do SoC vendors do
<geist>
but AFIAK both of those companies got rid of their cpu design team some years ago because they're too short sighted
<geist>
and went back to just licensing arm cores
<mrvn>
heat: add block around the core?
<geist>
what do they do? keep licensing arm cores
<mrvn>
blocks
<heat>
so what makes qualcomm faster than exynos or vice versa?
<heat>
if its the same design and similar fabs
<geist>
they're not necessarily. depends. they have a good GPU team
<geist>
well there's all that *not* core stuff that also matters
<geist>
memory controllers, gpu, peripherals, etc
<geist>
how aggressive they push the clocks, etc
<heat>
hmm
<geist>
there's infinity options there that dont just involve the cpu core
<heat>
so what you're saying is that ARM sets the low bar for performance and the "CPU Companies" just take it?
<geist>
but to rip out the ARm front end and replace it with a RV front end, you'd have to have your own in house cpu core to do it, and both of those companies kinda got out of that biz a few years back
<geist>
uh. what?
<geist>
'set the low bar for performance?' what are you talking about
<zid>
building rust takes me about 4-7 days
<zid>
pls stop porting things to rust
<heat>
geist, well they give you a design, they could try and do better, but they don't. so the only things they can change are memory controller stuff and peripherals (which I assume have no effect on raw CPU perf)
<geist>
sure, it's just money
<geist>
arm has multiple levels of licensing. you can license a core, in which ase you can' really modify it outside of the params you pay for it
<heat>
so it sounds like for many years it was just one company doing all the effort and then "vendors" did not really compete? until apple ofc
<geist>
you pay $X per unit for that
<geist>
you can become an architectural licensee, in which case you pay some N * X$ but then you're free to build your own cores provided they pass the arm architecture tests
<geist>
and now you need a team of folks to build it
<geist>
that's what apple, ampere, etc do
<geist>
in that case you dont pay per unit sold, so you can arguably break even after you ship N units
<geist>
and you can do what you want, provided it still is an ARM core
<geist>
er i mean is an architecturally compatible ARM core i mean
<geist>
not ARM the company owning it
<heat>
yes
<geist>
in the past both qualcomm (snapdragon, etc) and samsung (mongoose, etc) made their own cores
<heat>
why tf does samsung try with exynos then?
<geist>
but both of them pivoted back to using ARM provided cores the last 5 years or so, presumably because they couldn't justify paying a high end team of cpu designers, and ARM is/whas building good enough cores
<geist>
try what?
<heat>
to build a SoC
<geist>
they do, eynos is a soc
<heat>
I know
<geist>
gotta be more specific, what do you think samsung should do?
<heat>
but they use (or used) qualcomm at least in NA while doing exynos elsewhere
<geist>
they as in used where?
<heat>
phones
<heat>
(SoC)
<geist>
oh that's a completely different part of the company
<geist>
samsung competes with itself.
<geist>
samsung semiconductor and samsung phones and samsung washing machines are all completely different business units
<geist>
what do they call that in korean, one of those megaconglomerates
<geist>
dont confuse different parts of samsung with another
<geist>
Chaebol
<mrvn>
Did they split it up so it isn't a monopoly?
<geist>
재벌
<mrvn>
c7ac bc8c?
<heat>
even then, they use qualcomm for NA and exynos for rest-of-world. what's the point?
* geist
shrugs
<heat>
I thought they actually did do CPU design stuff and they were trying to, you know, build a nice CPU core
<zid>
Yea korea is weeeird, japan mostly broke up the zaibatsus
<geist>
they did, and then they decided to stop doing it
<geist>
i was dissapoint to, to be honest
<zid>
but korea is still "yea your house, shoes, air and water are all owned by samsung, deal with it"
<mrvn>
heat: don't try, do.
<geist>
but probably like qualcomm they decided it was too expensive to pay these cpu designers, so they stopped and laid them off
<geist>
and so they dont have the expertise
<gorgonical>
zid: they did, but there's still echoes of that system in japan. banks give companies like sony 0.1% loans or whatever
<zid>
well yea
<gorgonical>
it is certainly not as aggressively integrated as the zaibatsu were though, to be sure
<geist>
yah as far as i know the samsung and hyundai and whatnot in SK still pretty much run the show
<heat>
praise big corp
<zid>
korea is living the amazon dream
<gorgonical>
please deliver us to our cyberpunk dystopian dream
<geist>
oh LG too
<zid>
of having everything owned by amazon and having to drink your verfication can
<heat>
when do we start having sponsored IRC messages? - this message was sponsored by raycon
<mrvn>
gorgonical: do you really want to have an oxygen bill every month?
<zid>
Click this message to recover trace amounts of paperclips.
<gorgonical>
if the invisible hand of the free market will improve the quality of oxygen available
<gorgonical>
then yes
<gorgonical>
no price is too high
<geist>
this is getting pretty Phillip K Dickian
<mrvn>
gorgonical: now with 5% more O in the O2 atoms.
<heat>
"Sheriff has grown to include nearly all forms of profitable private business in the unrecognised country, and has even become significantly involved in local politics and sport,[2] with some commentators saying that company loyalists hold most main government positions in the territory"
<heat>
Sheriff owns a chain of petrol stations, a chain of supermarkets, a TV channel, a publishing house, a construction company, a Mercedes-Benz dealer, an advertising agency, a spirits factory, two bread factories, a mobile phone network, the football club FC Sheriff Tiraspol and its home ground Sheriff Stadium, a project which also included a five-star hotel.[5]
<heat>
samsung is a wannabe compared to Sheriff
<gorgonical>
They must be exceptionally influential. Only 3% of transnistrians work for them
<gorgonical>
Or their influence is hidden in subsidiaries etc.
* geist
wanders off to do some work
<demindiro>
Isn't that the same region that has a bunch of old weapons/munitions?
<demindiro>
Where Sheriff is
<heat>
it's a separatist region of moldova yes
<heat>
protected by a small old-soviet-now-russian regiment
<geist>
huh TIL: The modern word “Sheriff”, which means keeper or chief of the County, is derived from the Anglo-Saxon words “Shire-Reeve”.
<heat>
based on an old weapons silo of some sorts, probably what you're referring to
<netbsduser`>
i always thought it came from sharif
<geist>
yah i was surprised to find it's a proper english word
<geist>
and not a loaner
<zid>
are we counting french as loaners here
<geist>
yah
<zid>
wow, we're nearly at a thousand years and geist still not forgiven 1066
<zid>
(wrost day of my life)
<netbsduser`>
take up the good old cause, throw off the norman yoke
gildasio has quit [Ping timeout: 255 seconds]
gildasio has joined #osdev
<heat>
remember yesterday where I wrote a patch for a rando to save a feature?
<bslsk05>
lore.kernel.org: [PATCH] ACPI: Make custom_method use per-open state
<zid>
can we remove all of acpi next
<heat>
noooooOOOOooooooOOOooooooooo
<heat>
acpi very god i promise
<netbsduser`>
i have some nice words to say about NXP: no idea who they are, they seem to own the 68k series now, but they've uploaded fully texted PDFs of the manuals to all the 68k series cpus
<netbsduser`>
just been following the 68040 manual to start work on a 68k port of my kernel
<mjg>
:)
<mjg>
how is netbsd doing on the cpu?
<mjg>
i think it was supported up to some point(?)
<heat>
netbsduser` doesn't use netbsd
<heat>
no one uses it, it's a myth
<mjg>
makes sense
<gorgonical>
but didn't they do that thing where they put lua into the kernel
<gorgonical>
or was that someone else
<heat>
people using netbsd is like freebsd devs using freebsd
<mjg>
it was them but i don't think it goet anywhere
<mjg>
heat: OH i'm using it!
<kof123>
yes, and nowadays there are county sherriffs. or city has the same redundancy. reeve of the shire shire
<kof123>
re: sherriff
<gorgonical>
that's a shame. what's not to love about the lua stuff?
<kof123>
*shire reeve of the shire
<heat>
oh oh i'll start
<heat>
1) lua
<heat>
2) lua in the kernel
<gorgonical>
i have yet to hear about something you like, heat
<heat>
you
<gorgonical>
aww
<heat>
<3
<heat>
that is also wrong btw, I like linux and glibc
<netbsduser`>
mjg: still runs well
<netbsduser`>
i have an sd card with it installed on my actual amiga
<mjg>
is that a current version?
<heat>
real talk i also enjoy freebsd and netbsd
<mjg>
i know of a guy who is running a ntebsd 5 fork on sparcstatin
<mjg>
and does not udpate because things got too slow after that
<netbsduser`>
it's an old -current, i think about 2 years old
<mjg>
what's the amiga and dou have an accelrator card or some other fpga to fake it?
<heat>
mjg, things that run on SPARC tend to get slow, you should know that
<netbsduser`>
i'll upgrade to the latest -current at some point (there's wsfb with xorg support now)
<netbsduser`>
it's an a2000 with a tekmagic/060 accelerator
<mjg>
that changes things does not it
<mjg>
Processor: 040@40MHz or 060@50MHz(66MHz)
<mjg>
Max Ram: 128MB
<netbsduser`>
i have the latter and a full 128mb
<mjg>
i hear vamprie or whatever the name can do way etter, but then again it is almost a complete replacement
<netbsduser`>
it's definitely the envy of anyone living in 1994 or thereabouts
<netbsduser`>
vampire has no MMU, or rather they claim to have a custom MMU but there's no documentation of it nor have they released a driver
<mjg>
but amigaos works on it?
<mjg>
ithought it has vm separatin
<netbsduser`>
yeah, and i've heard with better compatibility for older apps and games than does the 68060 have
<heat>
freebsd is *fast*, netbsd is *portable*, openbsd, dragonfly bsd is *interesting*
<mjg>
are you serious mate
<mjg>
you sound like a reddit user
<mjg>
from time to time somoene asks what's the diff between the bsds and the above rolls out
<mjg>
with openbsd being secure
<heat>
nothing I said is wrong
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<mjg>
i don't know if netbsd is really portable
<gorgonical>
isn't that their whole motto thoughh
<mjg>
it did get several ports, but how (not)easy was to create them
<gorgonical>
a good point. the distinction between "portable" and "well-ported"
<mjg>
is it really more portable than freebsd or people just sat through it
<mjg>
it is a genuine inquiry and i would not take the portability claim at face value
<gorgonical>
That argument really boils down to the same as asking if L4 is more portable than Linux. Is netbsd less complex than freebsd?
<mjg>
similarly, the 'freebsd == f4s5 bro' is not exactly ture, is it
<heat>
is it not?
<heat>
you yourself say it competes with our good old commie unix
<mjg>
if by fast you mean on par with linux or at least in the ballpark, it is true for select workloads
<mjg>
but i can easily point at stuff where it fucking DIES
<mjg>
for example mount --bind on linux scales
<mjg>
while the freebsd equilvaent (nullfs) does not perform for shit
<mjg>
if you have to use it... hrhrhr
<mjg>
*vm* does not scale either
<heat>
ok so you're telling me it's objectively bad because it doesn't scale sometimes
<heat>
??
<mjg>
you got this backwards
<heat>
"fast" does not mean "fast in every possible way"
<mjg>
it does scale *sometimes*
<mjg>
to be fair, if you have a real workload on a box < 40-ish cores, it will probably be perfectly ok
<heat>
....
<mjg>
and even today this is the typical hardware
<heat>
OK SO ITS SLOW WHEN YOU HAVE A 3K XEON SO NOT FAST AT ALL
<mjg>
but if you have more serious needs, things quickly get murky and snowaball to total crap
<mjg>
dude being fast at laptop scale is liek... so 2010
<mjg>
i can tell you for example that pmap does not scale for shit
<heat>
how is 40 core laptop scale
<mjg>
laptop scale is 8 or so
<mjg>
this is where even netbsd mostly performs
<mjg>
openbsd of course does not
<mjg>
totally serious claim: you have to set some hardware standards. for better or worse i think behavior at about 100 cpu threads covers scalability ofr vast majority of real world deplyments
<mjg>
and consequently makes for a sensible base
<mjg>
for example supposed "big" bare metal boxes on amazon are 96 threads
<mjg>
at that scale there are woes
SGautam has quit [Quit: Connection closed for inactivity]
<mjg>
of course there is hardware way core-y than that and there freebsd does not perform for shit
<mjg>
but that mostly des not matter
<mjg>
all that said, if you throw in a vm with few cores somewhre, freebsd wont be a perf problem
<mjg>
similarly if you benchmark at laptop scale
<mjg>
even fucking oslaris scales to laptop scale :p
<heat>
if you use "lets see if this shit scales" on 100 core boxes as the "sensible base" then you'll be sad to realize only linux is fast
<mjg>
not true
<mjg>
i *beat* linux with my vfs work
<heat>
I highly doubt windows does
<mjg>
and then i made it back on top after fixing lockref
<mjg>
i'm gonna beat it agan later
<heat>
and I don't see any other possible contender here
<mjg>
contrary to popular belief linux drowns in slowness
<mjg>
but nobody is comparing it to other systems
<mjg>
see the lockref debacle, how was this unpatched for 9 years is beyond me
<heat>
ok so the only other OS that is fast is freebsd?
<heat>
didn't you literally call it "not fast"
<mjg>
fast as in faster than linux in *some* cases, freebsd is the only one i know of
<heat>
100 cores is not a sensible base man, sorry
<mjg>
but it is not that freebsd is doing anything amazing
<mjg>
what is a sensible base
<heat>
I can tell you that no cloudflare box has more than 60-something/70 cores
<heat>
maybe 50?
<mjg>
you may note that's already way past laptop scale though
<heat>
it is
<mjg>
you can expect vm to be a problem at that scale for example
<heat>
yes but is it slow?
<demindiro>
If you're at the point you actually have a use for 100 cores, aren't you then already at the point you can use multiple machines?
<demindiro>
At which point I assume core count per machine matters less?
<mjg>
demindiro: you may have a workload which needs a lot of parallelism and fast transfer across nodes
<demindiro>
And you can have a more sensible number like 16 cores/machine if you use e.g. Ryzen VPS
<mjg>
heat: freebsd vm, on that scale, yes
<mjg>
heat: i do have patches for it though
<heat>
freebsd works fine for netflix's scale
<heat>
so...
<mjg>
that's a common fallacy you are falling into dawg
<heat>
if it did not, I would assume they would just use linux
<mjg>
netflix has a highly specific workload and they optimized their own freebsd fork to perform for that workload
<mjg>
it does not translate for more generic cases
<heat>
sure
<mjg>
most notably, netflix workload does not mmap/munmap files
<mjg>
and this is where the primairy bottleneck lies, along with page fault handling
<heat>
the problem is that you point to synthetic benchmarks and say "look, $os is slow!"
<mjg>
i did not point at synthetic benchmarks here
<mjg>
or any bench for that matter
<gorgonical>
quick question: what's the purpose of a memsiz=0,filesiz=0 loadable program header in an elf file?
<heat>
if you're at the point where the OS is used in production for a large-ass CDN, it is not slow, period
<mjg>
if you want i can point you at a real workload which shows how it sucks
<heat>
gorgonical, none, where did you see it?
<gorgonical>
in the kernel I have
<mjg>
the workload being building linux
<gorgonical>
So possibly a weird linker artifact from a wonky script?
<heat>
gorgonical, pastebin
<heat>
i actually had a bug with some wonky program headers in a linker script a few weeks back because that phdr was empty and bfd still wanted to spit it out
<gorgonical>
oh there is a phdrs section in the script, you were right
<heat>
yes
<heat>
your user segment is empty
<heat>
bfd doesn't care and still outputs it. gold and lld do not
<gorgonical>
I wonder what that's a holdover from
<heat>
also what's up with your fucking segment permissions
<heat>
data RWX??
<gorgonical>
This is usually used for hpc where security is less important
<gorgonical>
And also I don't know, this code is basically reused for the last forever
<gorgonical>
I'm not offering excuses, only what I know lol
<heat>
your kernel is very weird
<gorgonical>
it is indeed
<heat>
looks half copied from linux
<heat>
or more than half
<gorgonical>
you're right, it is. the basic idea was to take linux and strip out all the extraneous shit that isn't useful for hpc applications
<heat>
huh
<gorgonical>
so like there's no interactivity support at all. you pass a single initrd and that's your only program
<gorgonical>
there's an extension that allows you to run other programs in a shell-like fashion, but it's typical use-case is just run-and-done a single binary
<heat>
i mean I guess in theory you stop being able to use large pages if you do proper perms, unless you large-page align segments
<heat>
actually don't know if large/huge pages are a big win in the kernel
<heat>
interesting question
<moon-child>
I heard hugepages really suck on linux
<moon-child>
because when you 'downgrade' a big page to a bunch of small ones, it sends a separate tlb shootdown for each one
<moon-child>
instead of ipi and batching it
<heat>
that should not be true
<heat>
and even then, in this case, you're not downgrading anything
<heat>
well, my "that should not be true" assertion comes from the fact that linux does indeed support shootdowns with more than one page. so unless their large pages breakup code is really shit, it should not be an issue
<moon-child>
idk I just heard that somewhere. Could be wrong
<geist>
or you just globally flush
<geist>
it depends a lot on the arch
<geist>
most sane arches make it pretty clear that a TLB flush on a large page should shoot down any matching TLBs, including the entire page
<geist>
even if internally the TLB 'cracked' the entries into multiple smaller ones
<geist>
but there is probably some dumb edge cases
<geist>
on ARM for example you need to do a break-before-make there which is pretty unfortunate
<heat>
what's the algo to break up a large page pte? alloc a page table, fill it with the entries you want, atomically set?
<heat>
then invlpg or whatever
<heat>
(also fwiw doing this on x86 will always trigger a global flush since the tlb invlpg ceiling is 33)
<geist>
depends. for break before make on ARM you must kill the old page, shoot it down, sync, then add new pages
<clever>
i just had a bit of a crazy idea, what if the TLB could test if 2 slots are consecutive in both physical and virtual?
<geist>
for coherency reasons with the A and D bits basically
<clever>
and auto-merge them into one TLB entry?
<clever>
and they also have the same perms
<geist>
problem with auto merge is things like the A and D bits. you have to remember what the original page was to write it back properly
<heat>
actually you only need 1 invlpg in all cases
<heat>
it Just Works for the large pages as you said
<heat>
nice.
<clever>
geist: does the cpu update the accessed bit on every access, or maybe only upon TLB miss when it reads the tables?
<geist>
its a lot of the complexity of the ARM page tables, which is why in general merging pages like the contig pages on arm, and a new riscv extensiosn i was just reading about always say 'you cant predict which of the sub pages A/D gets written back to'
<geist>
clever: the latter
<clever>
so merging TLB entries would potentially result in less TLB misses, and the access bit updating less
<geist>
for example
<geist>
the A bit isn't so bad, but the D bit is more of an issue
<geist>
since D is written back potentially after an existing TLB entry has been floating around a while
<clever>
what was D again?
<geist>
dirty, modified
<heat>
i bet handling transient page faults on break-before-make sucks
<clever>
ahh
<geist>
heat: yeah, that's the issue
<clever>
yeah, thats more of an issue
<heat>
i mean, you can just get the PTE on page fault and check for the perms so, not really?
<heat>
idk
<clever>
and i assume the TLB also holds the addr of the page table entry its matched to?
<clever>
so A/D can update without having to re-walk?
<geist>
in user space i think it's more of a transient thing. for kernel space it's a real problem
<heat>
geist, is the solution "don't mprotect in kernel space"?
<geist>
basically
<heat>
lol
<geist>
or at least dont split large pages there
<geist>
it's actually kinda a zircon problem that we haven't really solved yet
<geist>
ie, the physmap is set up with large pages, but there may be situations where we want to 'punch out' a spot in it, which involves breaking a large page
<heat>
don't you need it on perm changes too?
<geist>
and then you have break-before-make
<geist>
yes
<moon-child>
clever: interesting
<heat>
I remember you talked about it briefly in the fuchsia discord about ASAN
<heat>
(or KASAN I mean)
<geist>
yah we up until now have only had to do this at boot, where there's a single cpu running
<moon-child>
clever: seems like it would be kinda finicky to get right. EG you map y in between x and z; now you need to merge on both sides. But probs still doable
<geist>
ie, for marking kernel pages as XN after doing soem boottime patchups
<heat>
would it just be a "write protected vs writable" thing on KASAN?
<geist>
if it's a single cpu you're 'safe' because you can just make sure you dont fault on what you're fixing up
<heat>
and the big q is how tf do you solve this
<geist>
but it's when another cpu comes along and faults on what you're BBMing
<geist>
short of halting all the other cpus, i dunno
<heat>
sucks
terminalpusher has quit [Remote host closed the connection]
<heat>
the gang checks linux source
<geist>
i'm sure there are more and more elaborate strategies you can use to fix up the problem after it happens
<geist>
but in general the best solution is to avoid having the problem in the first place
<clever>
geist: oh, but i can see one solution to this, a new flag in the paging tables, that allows TLB merging and tells the cpu you dont care about A/D being out of date
<clever>
it could be used for kernel mappings, mlock() stuff, and stuff you dont plan to swap
* geist
nods
<clever>
then the entire kernel .text would always be 1 TLB slot
<clever>
and would basically never miss
<clever>
and it would be more flexible then just having 16mb pages
<clever>
because it wont be limited to a power of 2
<heat>
geist, seems that the idea around linux kasan is that they just keep the dynamic shadow bits (vmalloc) unmapped I think
<heat>
so this is a non issue
<clever>
but then the TLB check has to be range based
<heat>
i guess you can intercept this on a page fault and kasan still works
<geist>
(sorry, a bit busy today, trying to ignore irc. please dont tag me, makes my phone bloop in the other room)
<clever>
kk
<heat>
sorry
<geist>
no worries, just trying to heads down on something
<clever>
is risc-v based on a soft mmu?
danilogondolfo has quit [Remote host closed the connection]
<clever>
that would let you implement such an idea without changing the cpu
<heat>
like "if (is_kasan_shadow(fault_address) && is_vmalloc_addr(shadow2addr(fault_address))) bad_kasan();"
<heat>
no
<clever>
if the tlb is range based
<heat>
erm s/bad_kasan/bad_vmalloc_access/
<heat>
they actually do this for NULL accesses as well
<zid>
heat stop pming me your null access
air has quit [Remote host closed the connection]
air has joined #osdev
slidercrank has quit [Ping timeout: 252 seconds]
demindiro has quit [Quit: Client closed]
<mrvn>
woudn't the cpu simply only merge TLB entries when the A/D bits match and also split entries when A/D changes?