<geist>
heat: it's weird. it's kinda unique, like they had some grand vision there but then didn't really follow through
<geist>
it's basically a big virtual register of all the state bits, some of which get flattened into SPSR on exceptions
<geist>
but then 'unpacked' on eret
<geist>
so there's some sort of logic there when you thin kabout it that's kinda nice, because it means each of the interesting classes of bits in PSTATE get their own virtual register you can access indpendently
<geist>
ie, DAIF or SPSel, etc and you can fiddle with those bits with dedicated instructions
<geist>
so it's kinda nice when yuo think about it. sort of akin to sti/cli really modifying a larger register
<geist>
but it is a bit weird when you first see it
<heat>
daif is REALLY weird
<heat>
daif works like spsr but masked, but daifclr and daifset work with the DAIF bits directly (so msr daifset, #3 sets I and F)
<geist>
yep. and like i said thing of SPSR as a flattened version of relevant PSTATE bits
<geist>
it's not so much a register as a container for the bits, that is used on save/restore
<heat>
translation fault level 0 means the TTBR isnt correct right?
<geist>
i think that can mean an entry at 0 isn't present
<geist>
it, i faulted and the level in the page table i was scanning was at level 0
<geist>
though double check the way the levels are numbered
<geist>
i always forget, it might count down
<heat>
yes, looks like it
<heat>
wait, i forgot I demand fault everything lol
<heat>
"Why am I getting a page fault?"
<geist>
also be careful about the accessed bit, if you dont want to get any extraneous access faults, always pre-set it
<heat>
i need to decode ESR into something vaguely useful
<geist>
oh that reminds me, someone wrote a nice little python script for decoding ESRs in fuchsia
<geist>
though i think there's also a web site that does it
<heat>
i guess page faults are data aborts and instruction aborts?
<geist>
correct. the data vs instruction are whether or not load/store or instruction fetcher triggered it
<geist>
then within that as a result of it being that the bottom part of the ESR has a bunch of infos about more stuff
<geist>
omg what i wouldn't give for RISCV to give me *anything*
<geist>
now that i have it wired up for zircon the fact that riscv doesn't tell you anything about the page fault means we have some actual issues in the VM
terrorjack has joined #osdev
<heat>
i was pretty happy with scause?
<geist>
yeah it's insufficient for our VM. notably the only thing riscv tells you is what the cpu was doing when it page faulted, not why
<heat>
wdym?
<geist>
ie, instruction, read, write. that's it. doesn't say if it was because page not present, permission fault, or access fault
<geist>
the latter is a real issue because you can't fast track dealing with the A bit like you can on ARM
<heat>
ohhh right
<heat>
x86 doesn't either, or does it?
<geist>
x86 has at least the not present or permission bit
<heat>
in any case, I go down the page tables on every PF for the PTE
<geist>
and doesn't have access faults
<geist>
yah basically you have no choice but to do that in RV so you can try to guess why the fault happened. for access faults it's a drag, becaus eyou can fast track that on ARM
<geist>
ie, just directly drill into the page tables and set the bit and get out without consultin any of the mapping data
<heat>
arm even has an instruction for grabbing ptes lol
<heat>
cisc-iest risc
<geist>
yah the arm 'query what is here' is fantastic
<geist>
the only annoying part is it requires you write an address in one reg and read the dta in another, so it has to be done with preempt disable
<geist>
apparently that's so useful apparently that's one of the extensions apple has in their cpu: a single instruction to query
<heat>
yeah
<heat>
i was imagining they would be placing the data on the register you pass in (as an in-out kind of thing)
<geist>
there are rules about that method of course: it can't cause a page fault but it can cause a page table walk and a TLB entry to be brought in
<geist>
yeah, the official ARM one doesn't which is strange, but i thin it's because it goes way back into the armv6 days, so it's kinda a backwards compatibility thing
<heat>
are interrupt vectors an x86 thing?
<geist>
whatcha whatcha whatcha mean?
<heat>
like irqN mapping to an interrupt vector (so you already know what IRQ caused it) etc
<heat>
it seems that both riscv and arm just expect you to Figure It Out
<geist>
yep that's largely an x86 thing
<geist>
though of coruse riscv has the vectorewd stuff too, optional, but it's not really selecting an external IRQ that way
<geist>
it's really only giving yuo separate vectors for things like timer, IPI, etc
<geist>
also note arm cortex-m has hella vectored irqs
<geist>
but the whole way interrupts and whatnot works completely different in armv[6,7,8]m
<geist>
tis why it's a separate spec
<geist>
but that makes sense: for an embedded or lower end thing having separate vectors helps the decoding logic, makes the dispatch faster and more efficient
<geist>
but for modern higher end stuff the dispatch is pretty much always software dynamic anyway so there's no point having separate vectors really
<geist>
even the intel FRED stuff routes everything through one vector, IIRC
<heat>
if you have multiple interrupt controllers do you just poll each one for pending irqs?
<heat>
it's just kind of weird if you know the irq nr already (if your interrupt logic isn't just a simple IRQ# line)
<geist>
yep
<geist>
yeah but the key is the 'know the irq nr' is an external concept to the ARM core
<geist>
as i the core has no particular allegiance to the interrupt controller, so it'd have to have a generic mechanism to hand the irq number to it
<heat>
are the irq chips not part of the core itself?
<geist>
which of course they could have designed, but i think it's just not The Way
Jari-- has quit [Ping timeout: 250 seconds]
<geist>
no they're not at all. that's why you can have abominations like the broadcomm soc in rpi1-3
<geist>
it uses its own curstom interrupt controller that's not GIC based
<geist>
really the only external interaction is the IRQ/FIQ lines that the GIC talks to on all of the cores
<geist>
that was that bigass image you pasted yesterday or day before from the GIC manuyal that was confusing
<geist>
it was showing how a gic would wire up between a bunch of external irqs and a bunch of cpus
<heat>
do high performance cores (ampere, maybe apple, etc) also not have the gic embedded in-core?
<heat>
or <insert irq controller here>
<geist>
well to be clear 'in core' i mean as 'not part of the cortex-a53 or -a55 or whatnot'
<geist>
in core as in part of the same soc, absolutely
<geist>
it's all just a big pile of verilog at some point
<geist>
(but yes, apple also uses their own custom IRQ controller)
<heat>
ah
<geist>
makes sense anyway: a common arm soc has a heterogeneous pile of varios arm cores all within the same inner domain
<heat>
i wonder how many processors does a modern x86 cpu have :v
<geist>
4 a55s, 2 cortex-x1s, etc. none of the individual cores themselves 'know about' the irq controller, but the soc has to implement one
<geist>
so it's a bit more abstract than x86 in that regard
<geist>
and really this is eactly the same as riscv: each core in a riscv soc has one or more exteranl irq inputs, probably mapping to machine mode and supervisor mode at the minimum
<geist>
and thus you have a PLIC with 2 targets per core, etc
<heat>
all these pretty architectures haven't met x86, pragmatism itself
<heat>
"how many things do you want on the CPU die? yes."
Vercas694 has quit [Remote host closed the connection]
<heat>
let me train pcie using internal cpu registerz
Vercas694 has joined #osdev
<heat>
i'm really interested in opensil, i want to see part of the ugly bits they're hiding in blobs
<heat>
although the funnier stuff is probably in the PSP itself
elastic_dog has quit [Ping timeout: 248 seconds]
elastic_dog has joined #osdev
[itchyjunk] has quit [Ping timeout: 260 seconds]
[itchyjunk] has joined #osdev
voidah has quit [Ping timeout: 265 seconds]
Arthuria has quit [Remote host closed the connection]
voidah has joined #osdev
bradd has quit [Remote host closed the connection]
bradd has joined #osdev
heat has quit [Ping timeout: 265 seconds]
heat has joined #osdev
<heat>
woohoo im in user space
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #osdev
bgs has joined #osdev
hmmmm has quit [Remote host closed the connection]
hmmmm has joined #osdev
bradd has quit [Remote host closed the connection]
bradd has joined #osdev
bradd has quit [Remote host closed the connection]
<geist>
nice!
<geist>
adding arm64 to your system or building a standalone thing to test?
<heat>
adding it to my system
bradd has joined #osdev
bradd has quit [Remote host closed the connection]
bradd has joined #osdev
bradd has quit [Remote host closed the connection]
<geist>
woot
bradd has joined #osdev
heat has quit [Remote host closed the connection]
heat_ has joined #osdev
m5zs7k has quit [Ping timeout: 255 seconds]
xvmt has quit [Ping timeout: 255 seconds]
morgan has quit [Ping timeout: 255 seconds]
Patater has quit [Ping timeout: 255 seconds]
invalidopcode has quit [Quit: Ping timeout (120 seconds)]
MrBonkers has quit [Remote host closed the connection]
invalidopcode9 has joined #osdev
xvmt_ has joined #osdev
wlemuel has quit [Quit: Ping timeout (120 seconds)]
m5zs7k_ has joined #osdev
wlemuel has joined #osdev
xvmt_ is now known as xvmt
goliath has joined #osdev
Patater has joined #osdev
morgan has joined #osdev
MrBonkers has joined #osdev
bgs has quit [Remote host closed the connection]
m5zs7k_ is now known as m5zs7k
slidercrank has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
gildasio2 has quit [Remote host closed the connection]
gildasio2 has joined #osdev
heat has joined #osdev
heat_ has quit [Ping timeout: 240 seconds]
GeDaMo has joined #osdev
pmaz has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
invalidopcode9 has quit [Remote host closed the connection]
heat has quit [Ping timeout: 248 seconds]
Vercas694 has quit [Remote host closed the connection]
Vercas694 has joined #osdev
justmatt has quit [Quit: ]
justmatt has joined #osdev
bauen1 has quit [Ping timeout: 240 seconds]
xenos1984 has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
xenos1984 has quit [Ping timeout: 265 seconds]
Burgundy has joined #osdev
epony has quit [Remote host closed the connection]
<GeDaMo>
Is 'gog step' a new kind of dance music? :P
<sakasama>
No. It's a revolution.
zid` has joined #osdev
zid` is now known as isgog
<isgog>
I am gog now.
<gog>
gog and isgog
* sakasama
segfaults.
<isgog>
do you like my hostname gog
<gog>
gog.isgog() ? "it's gog" : "it's not gog";
<isgog>
fakegog*
<GeDaMo>
ungog
<gog>
how did you make it goggles.dot.gog.dot.goggendorfg
<gog>
oh right
* gog
prrr
<isgog>
[15:44] * Dns resolved goggles.dot.gog.dot.goggendorf.at to 2001:470:1f09:1cfb::606
<isgog>
It just me.
<isgog>
gogs can do these things
<Ermine>
gogn't
<GeDaMo>
You are !gog :|
Ermine is now known as isnotgog
<sakasama>
I am ~gog.
<isnotgog>
I am definitely not gog
<gog>
i am -gog
<sakasama>
Lies.
<gog>
so i'm sakasama + 1
<sakasama>
gog is not an involution. I refuse to accept it!
isgog has quit [Remote host closed the connection]
isnotgog is now known as Ermine
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
Brnocrist has quit [Ping timeout: 248 seconds]
heat has joined #osdev
<heat>
i think im corrupting the stack :(
<heat>
0xffffffff8017e060 <+0>: msr daifset, #0x3
<heat>
0xffffffff8017e064 <+4>: wfi
<heat>
0xffffffff8017e06c <+12>: b 0xffffffff8017e064 <halt()+4>
<heat>
0xffffffff8017e068 <+8>: wfi
<heat>
sweet loop unrolling!
<froggey>
stop corrupting the stack then
<heat>
doge i debugged for like 5 hours yesterday
<gog>
stack stack
<heat>
i can't tell what type of bug this even is
<heat>
it may be a TLB problem, but I don't think QEMU expects really tight tlb semantics hereeeeeeeee
<heat>
and as far as I can tell, BBM only applies to SMP, i'm not doing SMP so that shouldn't really be a problem I think
goliath has joined #osdev
awita has quit [Ping timeout: 255 seconds]
lanodan has quit [Ping timeout: 248 seconds]
[itchyjunk] has quit [Ping timeout: 240 seconds]
MrBonkers has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
lanodan has joined #osdev
MrBonkers has joined #osdev
[itchyjunk] has joined #osdev
epony has quit [K-Lined]
theboringkid has joined #osdev
lanodan has quit [Ping timeout: 248 seconds]
lanodan has joined #osdev
<gog>
hi
* kazinsal
pets gog
<heat>
gog teach me how to single step in arm64
theboringkid has quit [Ping timeout: 240 seconds]
xenos1984 has quit [Ping timeout: 256 seconds]
* gog
prr
<gog>
i don't know anything about arm64
<zid>
heat: a steady hand and a toggle switch
xenos1984 has joined #osdev
theboringkid has joined #osdev
<mjg>
arm64 does not know anything about you either
<gog>
i doubt that very much
<heat>
the stack is very much fucking itself, it seems
eroux has quit [Ping timeout: 265 seconds]
<heat>
i want to pass away
<heat>
i had the kernel - user ABI wrong
<heat>
fstat was overwriting the stack :)))
<zid>
nice
<zid>
when are you adding user accounts so I can finally root your OS
<heat>
i already have em
<mjg>
i added a backdoor to onyx
<mjg>
bullied heat into adding it under the guise of depessimization
<heat>
or optimization as non-polish people call it
lanodan has quit [Ping timeout: 264 seconds]
<gog>
is it
<mjg>
i already explained the difference
<heat>
heck yeah i'm in actual userspace without crashing!11!!!!1111!!!!!1
lanodan has joined #osdev
<heat>
ironically I considered this aproximately 15-18 hours ago
<heat>
and it's not the first time I'm fucked by this
<heat>
i should add kernel abi == user abi tests
<heat>
linux has the weirdest variations in ABI for REASONS
<mjg>
congrats
lanodan has quit [Read error: Connection reset by peer]
Brnocrist has joined #osdev
lanodan has joined #osdev
theboringkid has quit [Ping timeout: 246 seconds]
xenos1984 has quit [Ping timeout: 248 seconds]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
gog has quit [Quit: Konversation terminated!]
xenos1984 has joined #osdev
slidercrank has joined #osdev
heat_ is now known as heat
<heat>
woah arm64 linux signals are funky
<heat>
they built a whole system of extensible records you can push to the sig context that show you the various register states (sve, fpsimd, etc)
Goodbye_Vincent has quit [Read error: Connection reset by peer]
Goodbye_Vincent has joined #osdev
<geist>
noice
<heat>
i'll need some extensive changes to how my vm is setup to accomodate for BBM
<heat>
because BBM is stupid
<heat>
in a bunch of places I just call vm_invalidate_range, which doesn't /really/ work here, so I'll need to bring in some code to my pmap-ish thing
<heat>
i don't know what your interpretation is, but it seems to me that you only need BBM to accomodate for SMP
<heat>
so as long as ncpus == 1, you don't need to do that whole charade
<geist>
you dont really need BBM until you do A and D bit, even with SMP
vdamewood has quit [Remote host closed the connection]
<geist>
until then the cpu never writes back to the page table entry
<geist>
but there are some careful memory barriers yo uneed to put in there as you fiddle with page table entries
<geist>
even on single cpu, because you can consider the page table walker to kinda be another cpu, and it's weakly ordered with regard to the cpu
<geist>
ie, modify an entry, barrier, then do a TLB sync, otherwise the page table walker may or may not see the new entry
<heat>
well, i'm following the arm arm, and they talk about BBM even before the hardware AD stuff
<heat>
do existing cores rely on it? maybe not
<geist>
there's a section where it says if you dont do BBM here are the ramifications of it
vdamewood has joined #osdev
<geist>
it basically specs out the worst cases, which is strictly better than just a blanket UNDEFINED
<geist>
also i think there's an implicit assumption that you have some sort of software lock so that only one cpu is messing with a section of a page table structure at a time
<geist>
ie, while you're futzing with a page table you're only really racing with other cpus writing back A and D bits
<heat>
if I have a range of memory, can I do BBM like "write 0 to these N entries and tlbi them one at a time, then at the end dsb"?
<heat>
you know, like a normal shootdown
<heat>
or do I need to synchronously do entry[n] = 0; tlbi; dsb; entry[n+1] = 0; ...
<heat>
it doesn't fit with their strict process but it does seem plausibly valid
danilogondolfo has quit [Remote host closed the connection]
<geist>
nah you can do like write write write; dsb; tlbi; dsb
<geist>
basically you need to make sure the writes have made it out of the cpu before then trying to sync the TLB so that if the cpu wants to bring things back in again (or another cpu) it'll be sure to be seeing the new entries
<geist>
and the second dsb you need to synchronize the tlbi
<geist>
since tlbis themselves are weakly ordered
<heat>
hmm
<heat>
so I always need a dsb before a tlbi?
<heat>
except when unmapping I guess?
<geist>
dont worry too much about dsbs, they're not the end of the world in terms of performance. x86s have a bunch of these implicitly, it's more like you're just required to manually schedule flushes that would be happening on a stronly ordered one
<heat>
wait, even then
<geist>
yah, think of it this way: until you dsb the writes that you have previously posted may or may not have 'happened' from the point of view of *any* external observer
<geist>
like another cpu, or your own paging unit (since it's also an external observer)
<geist>
so you dsb to 'publish' the writes
theboringkid has joined #osdev
gog has joined #osdev
<geist>
so though you're not doing SMP right now you kinda are because the paging unit is kinda like another cpu
wlemuel has quit [Quit: Ping timeout (120 seconds)]
vdamewood has quit [Read error: Connection reset by peer]
<geist>
it's obviously more complicted than x86 but what's neat is it can be somewhat more efficient, since you're ot really required to synchronously flush each page, the tlbis are posted (and cross cpu) so you can batch them up
vdamewood has joined #osdev
<heat>
yes, so couldn't it be more efficient to not batch them at the end?
<heat>
although I guess then you need N dsbs
<geist>
right
<geist>
note: there is some subtle complexity when removing page tables that you should pay attention to if you havent already
<geist>
when disconnecting a page table itself, you have to flush the page walker cache (a bit on the tlbi instruction) and you must make sure you dont recycle the page into the PMM before you have fully flushed the TLB
Goodbye_Vincent has quit [Remote host closed the connection]
Goodbye_Vincent has joined #osdev
<heat>
hmm yes
<heat>
i don't handle that yet
<heat>
there are a lot of subtleties I managed to skip cuz hurr durr qemu tcg
<geist>
yah
<geist>
at least add a TODO about that. i was burned on it in zircon in early dev and it took a while to figure out
<geist>
recycling page tables and having that get subly corrupt was no fun
<heat>
do even crappy cores (a53, etc) speculate on all of that?
<heat>
and have fun issues with data barriers
<geist>
somewhat, but less so. speculation maybe less so, but they still track a fair amount of load/stores in flight
<geist>
so you can still end up with stores that are sitting around in a store buffer waiting for the cache line to fill while the cpu moves on, etc
<geist>
but the crappy cores still also look for things like copy loops and try to prefetch after a few iterations
<heat>
i should get onyx on my rpi zero 2 w
<heat>
i just need some output for debog
<heat>
i assume i'll find device tree warcrimes and the funny bcm irq chip there
<netbsduser`>
threads in, xeyes proceeds no further
<netbsduser`>
i am disappointed
alexander has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<netbsduser`>
kof123: yes although i don't want to download the zipfile
<kof123>
:D
<geist>
heat: yes. i think you will. that's the a53 version. the bcm stuff doesn't start resembling a reasonable core until whatever is in the rpi4, which is quad a72 based
<netbsduser`>
i've located where it hangs forever - _XFlush() in libX11 calls _XEventsQueued and there it stays waiting forevermore
<netbsduser`>
for messages on a socket which it never gets (and to my understanding, can't get, since it never did anything to evoke a response from X11?)
<heat>
geist, if all I have to deal with is a weird interrupt controller im OK with that
<geist>
yah it's not too weird, just different
<geist>
but also it's not terribly documented, you might have to sleuth through various sources to figure it out
<geist>
but it's also quite simple
alexander has joined #osdev
Goodbye_Vincent has quit [Remote host closed the connection]
Goodbye_Vincent has joined #osdev
vdamewood has quit [Quit: Life beckons]
heat has quit [Ping timeout: 248 seconds]
heat has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
meta-coder has joined #osdev
gildasio2 has quit [Ping timeout: 255 seconds]
awita has joined #osdev
Goodbye_Vincent has quit [Remote host closed the connection]
Goodbye_Vincent has joined #osdev
<heat>
geist, is it worth it to use x18 for anything other than SCS when enabled?
<heat>
currently my pcpu stuff is all on TPIDR and I need a shitty sequence to load that and do some pointer arithmetic
<heat>
storing something like the struct thread* on it may be an idea
<heat>
ofc, conditional on not having SCS enabled (not that I'm currently supporting that, anyway)
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
innegatives has joined #osdev
<innegatives>
When 8086 RESETs the CS is set to 0xFFFF, boot sequence though starts executing at 0x0000:0x7c00. Does this mean BIOS sets CS to 0x0000 before boot sequence?
Goodbye_Vincent has quit [Remote host closed the connection]
Goodbye_Vincent has joined #osdev
bauen1 has joined #osdev
<geist>
heat: you can use it for the current cpu pointer or something like that i fou want
<geist>
otherwise the default use for x18 is just a third fully temporary register (x16, x17, and x18)
<geist>
well, i guess x9-x15 are also temp
<geist>
x16 and x17 have some interprocedural use cases, for GOT shim and whatnot
innegatives has quit [Quit: WeeChat 3.8]
<geist>
after having dealt with riscv for the last month or two i am starting to really like the way you just use ABI register names all the way down there. it's really nice. i definitely have the ARM abi memorized so that it's no big deal but it really helps when writing riscv asm to just use the a/t/s stuff
<geist>
i used to be kinda down on the notion of baking the ABI at that level, but now i'm pretty sold
<heat>
oh the innegatives fella left
<heat>
anyway yeah using x18 may be an idea, although I don't think linux uses it for anything either, besides SCS
<heat>
same for fuchsia I think?
<heat>
yessss the riscv register naming is useful
<kof123>
yes #$@#@$$#@ innegatives left. someone asked this before too, ack seems to not trust it. BOOT_SEGMENT = 0x07C0 This code makes up the PC boot sector [...] The PC will load this sector to 0x07C0:0000 and jump to it [...] but it won't necessarily do it in a sane way ! (some BIOSes jump to 0x0000:7C00 instead). So, we need to fix that. jmpf BOOT_SEGMENT : start2 [...] We're running in tiny mode, so it's just ! a ma
<kof123>
r of copying the contents of cs (already been set up by the jmpf)
<heat>
i don't know whether he was talking about the actual 8086 (why?) or a more contemporary 80386, but there's a plenthora of steps between POST and booting
<heat>
on a 386+ reset the CS value doesn't even matter, there's a super special segment cache that lets it run at 4GB - 16
<geist>
oh yeah i remember readin ghtatsomewhere
<geist>
ie, it 'looks like' it's running at the legacy CS but at least until you reload it it's really just below 4GB
bauen1 has quit [Ping timeout: 240 seconds]
<kof123>
i wonder if they specifically mean "reset" and not "boot"
bauen1 has joined #osdev
<heat>
reset = boot = S3 resume
<heat>
it's all the same codepath
Goodbye_Vincent has quit [Remote host closed the connection]
theboringkid has quit [Quit: Bye]
theboringkid has joined #osdev
Goodbye_Vincent has joined #osdev
<kof123>
hmm, i just vaguely remember people trying to do "fast reboot" for some reason
meta-coder has quit [Quit: leaving]
slidercrank has quit [Ping timeout: 255 seconds]
joe9 has joined #osdev
gildasio2 has joined #osdev
<heat>
geist, re: tlb flushing, what's a "Context Synchronization Event"?
<geist>
it's defined somewhere in the manual. it's a list of situations, i think like an ISB
theboringkid has quit [Quit: Bye]
<geist>
there's a section on it
<heat>
ah ok, thanks
<heat>
i was thinking it was a zircon thing
<geist>
no
<geist>
in the ARMv8 manual i have here, it's in the glossary, page 8678
xenos1984 has quit [Read error: Connection reset by peer]
<geist>
i think the part that you're probably seeing re ISB at the end of the TLB sync in the zircon code is because of
Goodbye_Vincent has quit [Read error: Connection reset by peer]
<geist>
basically among other things you can be sure that everything after the ISB is using the new TLBs but prior to that it may have been OOO and thus yolo
Goodbye_Vincent has joined #osdev
Burgundy has quit [Ping timeout: 240 seconds]
bauen1 has quit [Ping timeout: 240 seconds]
bauen1 has joined #osdev
xenos1984 has joined #osdev
<heat>
ugh BBM sucks
Goodbye_Vincent has quit [Remote host closed the connection]
Goodbye_Vincent has joined #osdev
goliath has quit [Quit: SIGSEGV]
weinholt has quit [Ping timeout: 265 seconds]
Turn_Left has quit [Read error: Connection reset by peer]
Goodbye_Vincent has quit [Remote host closed the connection]
Goodbye_Vincent has joined #osdev
Raito_Bezarius has joined #osdev
weinholt has joined #osdev
<kazinsal>
Complexity62195!
<kazinsal>
ah goddammit time to change that password
<kazinsal>
you're not my terminal!
<kazinsal>
always check what you're pasting shit into, kids
<heat>
[kazinsal@home-pc ~]$
<kazinsal>
sudo apt install buttsbuttsbuttsbutts
nyah has quit [Quit: leaving]
<mjg>
kazinsal: Algorithm90210
<kazinsal>
functionally, yes
<heat>
its funny how architecture porting is largely the same shit, just with a different smell
<mjg>
dog shit, cow shit, cat shit...
<kazinsal>
artisanal meerkat shit
<kazinsal>
(is the shit artisanal or the meerkat? either way, art is anal)
Goodbye_Vincent has quit [Remote host closed the connection]
Goodbye_Vincent has joined #osdev
awita has quit [Remote host closed the connection]