sinvet has quit [Read error: Connection reset by peer]
sinvet has joined #osdev
<Hammdist>
so I've run into another stumbling block. when I run qemu with -kernel and raspi3b it is in mmu "index" 0x16 ("E2") when executing the image. I try to install values to vtcr_el2, but the tcr readout from the page table walker side is zero, supposedly because "stage2" is distinct from "E2" to qemu. any ideas?
<heat>
in qemu you're not in EL2
nvmd has quit [Quit: WeeChat 3.8]
<clever>
unsigned int current_el = ARM64_READ_SYSREG(CURRENTEL) >> 2;
<clever>
printf("i am aarch64 with MIDR_EL1 0x%llx in EL %d\n", ARM64_READ_SYSREG(midr_el1), current_el);
<clever>
heat: you may also want to check the current el register, just to confirm where you are
<heat>
i know
<clever>
oops
<clever>
tab complete gave the wrong name
<heat>
:P
<clever>
Hammdist: ^
<Hammdist>
I am just past an `mrs x0, currentel` in gdb and it reads as 8 ... I forget even what that means
<bslsk05>
lwn.net: Following up on file-position locking [LWN.net]
<clever>
based on the bitshift from my code, that means your in EL2
<heat>
how the fuck?
<heat>
there's no way?
<heat>
unless they emulate EL2 in rpi3b mode??
<Hammdist>
it's that way when you select rpi
<heat>
the fuck
<heat>
but that must change if --enable-kvm then?
<qookie>
i mean that's how the rpi firmware leaves you
<Hammdist>
ah well I am on x86_64 host anyways, kvm plays no role it's all emulated
<heat>
its how most firmware leaves you
<geist>
that shoul change if enable-kvm yeah
<heat>
most EL2 capable stuff at least
<clever>
qookie: changed at some point, when LK was first written for the pi, it ran in EL1, but then RPF switched it to EL2 and broke LK
<clever>
and LK lacked the ability to detect this and switch
<heat>
good
<heat>
reject EL2, embrace EL1
<clever>
so it configured EL1's mmu, while in EL2, then flipped on the mmu, and *fault*
<geist>
so i got a bit of hit on hackernews today, when someone discovered newos.org
<geist>
had to update it, since the php was utterly broken
<geist>
for like the first time in 15 years :)
<heat>
hah
<clever>
geist: ive got good news, i went over that old arm64-shutdown branch again, copied arm64 chainload out, and got it fully booting linux on my pi3
<heat>
how did it come up?
<heat>
hi-ku?
<clever>
so i should probably PR that at some point
<geist>
dunno, someone just discovered it and posted a link
<geist>
then people mostly trashed the web page being broken :)
<heat>
Fuscia
<geist>
yeah after 8 years of this project one thing i learned is how to spell fuchsia
<heat>
dumb dumbs, it's obviously spelt fucsia
<heat>
fushia
<Hammdist>
so what should I do? is it legit to modify regime_tcr in qemu to use the vtcr_el2 value in is "E2" mode? or will that just not match anything hardware would ever do?
<geist>
Hammdist: you can also just detect that you're in EL2 and drop to EL1
<geist>
that's what I do in LK, works well enough
<qookie>
why do you want to touch vtc, that's the virtualization-related register
<qookie>
s/vtc/vtcr
<geist>
yeah i dunno precisely what you're trying to *do* here
<clever>
geist: but i discovered 2 issues while fixing that, 1: vmm_create_aspace() doesnt allow an identity mapping at 0, due to USER_ASPACE_BASE(which also cant be zero), and 2: platform_reset is missing from aarch64
<clever>
2 i can easily fix and PR, but 1 is a bit more of a design question
<heat>
geist: how do hypervisors (like KVM) work in arm64? you just hvc when you need to do hypervisor stuff?
<qookie>
el2 has a regular tcr_el2 if you want to configure virtual memory
<geist>
clever: for 1 I'd probably just add some flag to the vmm_create_aspace() asking it to build an identity one
<Hammdist>
dunno it seems simpler to me to install paging in EL2 rather than "dropping" to EL1 which I've seen a lot of complicated code for
<geist>
that's basically what we have in zircon, based on more or less the same design pattern
<geist>
it's a different 'type' of aspace, one for precisely setting up identity maps
<jimbzy>
What a bummer. I was hoping my IC sockets would arrive this weekend, but it looks like they won't get here until Tuesday :(
<clever>
geist: yeah, my quick hack was VMM_ASPACE_FLAG_NULLPAGE, which allows a mapping in the lower 16mb, starting at 0
<Hammdist>
qookie: ah maybe I missed that option
<geist>
Hammdist: except now all the MSrs you touch from then on have to be the EL2 version of it
<heat>
please just switch to el1
<geist>
and EL2 has some limitations compared to EL1 (except with VHE extension, which the a53 does not have)
<geist>
ie, EL2 is nerfed, designed to just host a hypervisor, not a full system
<bslsk05>
github.com: lk/arch/arm64/asm.S at master · littlekernel/lk · GitHub
<qookie>
or am i confusing the virt registers and el2 vmem now
<geist>
qookie: basically, yeah. there is no TTBR1 without VHE
<clever>
my rough understanding, is that EL2 was designed for type-1 hypervisors, (like xen), so the hypervisor lives in EL2 and acts like a fully self-contained kernel
<heat>
wait
<heat>
what's EL3 again?
<clever>
and then you use hvc to make hypercalls into it
<Hammdist>
geist: ah that's massively helpful. I was looking at the linux kernel implementation of it and it boggled the mind a bit
<clever>
EL3 is secure-monitor
<heat>
ah
<geist>
it's intrinsically in secure mode, also optional. Apple silicon doesn't have it
<clever>
linux needs TTBR0/TTBR1, so it cant run in EL2
<heat>
good
<heat>
linux as a hypervisor is hypercursed
<clever>
so traditionally, linux leaves a stub in EL2, and has to RPC into it, to do every switch into another guest
<clever>
so linux is kind of a guest under a dumb hypervisor
<geist>
rght, and that stub probably runs in an identity map it leaves behind. that's wgat we do in zircon
<clever>
but VHE lets linux run in EL2, aliases a bunch of EL1 regs to the EL2 counterparts, and gives TTBR0/TTBR1
<geist>
*and* a vttbr
<clever>
so linux can live in EL2, but it acts like EL1
<geist>
right. VHE tends to show up in armv8.1+ cores, which a53 is not. a55 has it
<clever>
and when it wants to switch to a guest, it doesnt have to hypercall into a stub
<geist>
i honestly dunno what apple does in their silicon
<geist>
i know they dont have an EL3, but thats because they dont implement secure mode, so there's no reason to have a higher truth than EL2
<qookie>
iirc they force the use of vhe?
<geist>
possible, sure
<clever>
i'm surprised apple lacks EL3
<geist>
there's no reason without secure mode
<clever>
and secure mode
<heat>
this is so ARM im getting sick
<heat>
x86 descriptor table fans anywhere?
<clever>
kind of the point of EL3, is to have have a smaller audit surface, for the trusted code
<geist>
heat: ia64!
<geist>
clever: and you can run EL2 in non-secure mode. to do that you need to have a higher level that is secure
<mjg>
heat: loller
<mjg>
this is one unnecessary article
<mjg>
there is something i may or may not end up doing to
<clever>
geist: whats the highest address you typically see ram mapped at (or specifically, the LK binary loaded to), on aarch64?
<mjg>
which, if sent, would possibly deserve one
<heat>
which is?
<geist>
clever: well, *generally* something approximately 'the amount of ram in the system', approximately
<mjg>
namely once lockref() starts taking the spinlock *and* there is constant traffic
<mjg>
it cannot recover
<geist>
but i've seen a few weird outliers, like the Cavium Thunder X1, and the AMD Seattle
<clever>
the linux docs mention that at one point, it wasnt able to use any ram below the kernel load addr
<geist>
they have *crazily* huge physical address spaces, because
<mjg>
and i literally see it happen if i let will-it-scale run for too long
<clever>
so it was preferable to load the kernel to the lowest possible addr
<geist>
yeah, i generally do something like that. that's why there's the KERNEL_BASE and the KERNEL_LOAD_OFFSET or whatnot
<heat>
mjg: hmm, im not familiar with lockref
<heat>
you're only going to see that on REF-walk right?
<mjg>
heat: boils down to bumping or subbing from a ref
<mjg>
no
<mjg>
you see it for terminal entries
<mjg>
and in some other places
<mjg>
anyway you can stick to atomics for non-zero transition
<heat>
oh right
<clever>
geist: oh, and i just had an idea, the identity mapping could just SDRAM_BASE and MEMSIZE, that would allow identity mapping anything in "ram"
<mjg>
*normally* this kind of code does not have much trouble -- any count transition apart from 0 can be done with atomics
* geist
afks for a bit, getting some evening walk in
<mjg>
but lockref as implemented right now resorts to locking if it sees the lock taken
<mjg>
so once you get there, and there is constant traffic, it literally never recovers
<mjg>
i'm getting 4.8 mln ops/s and it suddenly drops to next to nothing
<mjg>
that 4.8 is already dogshit, but that's another story
<mjg>
all in all, lol
<mjg>
i'm gonna do some ptachen over the weekend, this is all freebsd-esque breakage
<mjg>
assuming you did not run into the lockref problem, top of the profile is apparmor
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<heat>
>apparmor
<heat>
LUL
<heat>
imagine running an LSM
<mjg>
it came with debian
<heat>
i know
<mjg>
you don't have it?
<heat>
fedora (used to come? comes?) with selinux
<heat>
no, arch doesnt have LSM support
<mjg>
:OOO
<heat>
my flamegraphs are the purest they can be
<heat>
except when I accidentally run something on a directory that is being inotify'd by vscode
<heat>
then you can kinda see some inotify overhead and its cute
<mjg>
you don't have init on allloc?
<mjg>
afair your vfs-related syscall perf was utterly shafted
netbsduser` has joined #osdev
<heat>
maybe
<heat>
i dont consider that impure
<heat>
as we've discussed :)
<mjg>
"flamed"
<heat>
im on windows right now, im happy and dont flame
<Hammdist>
thanks for your help all I would've been like a blind man in a cave without y'all help and assistance
terrorjack has joined #osdev
gog has quit [Ping timeout: 260 seconds]
netbsduser` has quit [Ping timeout: 248 seconds]
heat has quit [Quit: Client closed]
stolen has joined #osdev
Gooberpatrol66 has joined #osdev
SGautam has joined #osdev
Terlisimo has joined #osdev
<Hammdist>
heat: oh yeah I almost forgot I spotted a bug in mmu.h the #define for MMU_MAIR_ATTR3 has incorrect index. this would only affect anything if someone tried to use uncached memory (seems unlikely to me) but I thought I'd mention it
netbsduser` has joined #osdev
corank_ has quit [Remote host closed the connection]
netbsduser` has quit [Ping timeout: 248 seconds]
[_] has quit [Read error: Connection reset by peer]
gildasio has quit [Quit: WeeChat 4.0.2]
bradd has quit [Ping timeout: 246 seconds]
bradd has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
netbsduser` has joined #osdev
gxt has quit [Remote host closed the connection]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
gxt has joined #osdev
Yoofie6 has joined #osdev
Yoofie has quit [Ping timeout: 248 seconds]
Yoofie6 is now known as Yoofie
netbsduser` has quit [Ping timeout: 260 seconds]
slow99 has joined #osdev
agent314 has quit [Ping timeout: 256 seconds]
agent314_ has joined #osdev
gxt has quit [*.net *.split]
Vercas has quit [*.net *.split]
gabi-250 has quit [*.net *.split]
gabi-250 has joined #osdev
gxt has joined #osdev
Vercas has joined #osdev
<kof123>
TIL: quote: These are the two serpents, given and sent by Juno, (that is the nature metallic), the which the strong Hercules, that is to say, the sage and wise man, must strangle in his cradle < inevitable conclusion: Hercules uses 0-based array indexing for his labours
SGautam has quit [Quit: Connection closed for inactivity]
m3a has quit [Ping timeout: 240 seconds]
agent314_ has quit [Remote host closed the connection]
GeDaMo has joined #osdev
ThinkT510 has quit [Quit: WeeChat 4.0.2]
ThinkT510 has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
bgs has joined #osdev
Left_Turn has joined #osdev
Hammdist has quit [Quit: Client closed]
<sham1>
Must be the greek influence
Burgundy has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
Left_Turn has quit [Ping timeout: 260 seconds]
Left_Turn has joined #osdev
Left_Turn has quit [Ping timeout: 252 seconds]
Left_Turn has joined #osdev
Left_Turn has quit [Ping timeout: 248 seconds]
[itchyjunk] has joined #osdev
Left_Turn has joined #osdev
goliath has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 244 seconds]
Hammdist has joined #osdev
gog has joined #osdev
Turn_Left has quit [Ping timeout: 248 seconds]
SGautam has joined #osdev
Burgundy has quit [Ping timeout: 245 seconds]
dennis95 has joined #osdev
terminalpusher has joined #osdev
netbsduser` has joined #osdev
MiningMarsh has joined #osdev
Turn_Left has joined #osdev
Turn_Left has quit [Ping timeout: 246 seconds]
gog has quit [Ping timeout: 260 seconds]
nyah has joined #osdev
elastic_dog has quit [Ping timeout: 246 seconds]
<ddevault>
MBR and GPT both work :)
<ddevault>
500 lines of code for the driver that implements both formats
<ddevault>
though to be fair I don't do anything with the backup GPT, but I do verify the primary GPT's CRC
elastic_dog has joined #osdev
terminalpusher has quit [Remote host closed the connection]
gildasio has joined #osdev
<Jari-->
ddevault yeah its a failback, the backup GPT
Turn_Left has joined #osdev
joe9 has joined #osdev
Harriet has quit [Quit: SASL settings test]
Harriet has joined #osdev
sparklysara has joined #osdev
DanDan has joined #osdev
dennis95 has quit [Quit: Leaving]
netbsduser` has quit [Ping timeout: 245 seconds]
netbsduser` has joined #osdev
stolen has joined #osdev
<Hammdist>
so now I'm trying to write a context switching function somewhat based on this: https://github.com/littlekernel/lk/blob/master/arch/arm64/asm.S . however when I compile on an armv8 docker with debian sid gcc, I get "unknown mnemonic push -- push x28, x29"
<bslsk05>
github.com: lk/arch/arm64/asm.S at master · littlekernel/lk · GitHub
<Ermine>
ddevault: which one was more pleasant to work with?
CaCode has joined #osdev
<GeDaMo>
Hammdist: it might be something to do with unified syntax? I can't remember the details
<Hammdist>
yeah I think I copied from a .S file into gas syntax and that's the problem. wishing there was an example of how to push two registers in gas
<bslsk05>
github.com: lk/arch/arm64/include/arch/asm_macros.h at master · littlekernel/lk · GitHub
<immibis>
calling EL3 code "trusted" is a misnomer - this is the code that exists to steal all your data and lock you out of your own device. It's trusted by the people who are trying to do those things. It's untrusted by the people whose device it is.
<ddevault>
Ermine: MBR is simpler of course
* ddevault
shrugs
<ddevault>
neither is especially difficult to implement and GPT has clear advantages
dutch has joined #osdev
<immibis>
maybe the best partitioning scheme is something like LVM
<ddevault>
I will say the whole process of verifying the GPT primary and backup sectors, plus the partition tables, and restoring them if corrupted, is a bit complex
<ddevault>
but it's fine
<sham1>
Like partition sizes worth a damn
<Ermine>
ok, thank you for sharing
<immibis>
which is, of course, very complicated on purpose so it can do a lot of things
<immibis>
should the OS interpret the backup GPT or should it be left for fsck to do?
<ddevault>
perhaps fsck should do that
<ddevault>
but fsck checks *filesystems*
<ddevault>
so maybe a bit out of scope
<Ermine>
dskchk
<Hammdist>
ah thanks. surprising asymmetry of the syntax there but let's see what this does for now
<immibis>
well, whatever you call your disk error fixing tool
<sham1>
disk geometry check
<sham1>
dgck
<immibis>
disk image check, obviously
<immibis>
or disk information check
<immibis>
if you're going to try at lewd puns you have to do it properly
<sham1>
No but that just spells "dick" while fsck doesn't just spell out the pun
<sham1>
Although I do like the idea of it being the "disk image check"
CaCode has quit [Quit: Leaving]
<immibis>
then obviously it's dsck, disk check
wblue has joined #osdev
<sham1>
There we go
Burgundy has joined #osdev
wblue has quit [Quit: wblue]
SGautam has quit [Quit: Connection closed for inactivity]
m3a has joined #osdev
heat has joined #osdev
<heat>
Hammdist, oh, good to know, thanks!
<heat>
this is actually a bad bug, I don't want device memory to be write combining :)
<zid>
don't worry, registers are NEVER sequential
wblue has joined #osdev
wblue has quit [Client Quit]
heat has quit [Remote host closed the connection]
heat has joined #osdev
terminalpusher has joined #osdev
<mcrod>
hi
<mcrod>
stop, hamming time
<heat>
OMG so embedded im getting sick
* mcrod
slap
<mcrod>
embrace the embedded world
<mcrod>
we have cookies
<mcrod>
and RTOS
<Cindy>
os-9 os-9 os-9
<mcrod>
I'm serious though, wouldn't trade embedded for the world
<mcrod>
heat: by the way I went through blighttown with 12 vigor
<heat>
you mean vitality
<mcrod>
yesd
<heat>
yesd(8)
sparklysara has quit [Quit: Leaving]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 260 seconds]
gildasio has quit [Quit: WeeChat 4.0.2]
foudfou has joined #osdev
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
terminalpusher has quit [Remote host closed the connection]
Harriet is now known as Andrew
frkazoid333 has quit [Ping timeout: 248 seconds]
Andrew is now known as Harriet
gog has joined #osdev
dennis95 has joined #osdev
Harriet is now known as Meowrriet
nanovad has quit [Ping timeout: 246 seconds]
nanovad has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
Matt|home has joined #osdev
CaCode has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 260 seconds]
Meowrriet is now known as Harriet
frkazoid333 has joined #osdev
gog has quit [Ping timeout: 246 seconds]
m3a has quit [Ping timeout: 256 seconds]
goliath has quit [Quit: SIGSEGV]
<geist>
Hammdist: ah looks like you got the macro figured out
<geist>
yeah, was gonna say the push thing is a macro
<geist>
little bit of subtlty there that's not super obvious: on arm64 you *must* keep the stack 16 byte aligned at all times, hence why it always pushes 2 words at a time, including an extraneous xzr register
<geist>
heat: oooh that write combining device thing may be the source of your GIC/interrupt/timer problems
<geist>
since that would absolutely not matter until real hardware
<geist>
and would show up even on derpy, mostly in order cpu like cortex-a53
slow99 has quit [Ping timeout: 245 seconds]
slow99 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!]
<Ermine>
I've ridden my bike and now my legs hurt
<geist>
feel the pain!
<Ermine>
yeah
gog has joined #osdev
agent314 has joined #osdev
<Ermine>
gog: may I pet you
<gog>
yes
* Ermine
pets gog
* gog
prr
dude12312414 has joined #osdev
m3a has joined #osdev
heat has quit [Remote host closed the connection]
dude12312414 has quit [Client Quit]
heat has joined #osdev
m3a has quit [Ping timeout: 246 seconds]
<mcrod>
gog: may I also pet you
<gog>
yes
<gog>
i did a lot of walking today iam one tired cat
<bslsk05>
seiya.me: Exploring the internals of Linux v0.01 - seiya.me
<nortti>
"* 'schedule()' is the scheduler function. This is GOOD CODE! There * probably won't be any reason to change this, as it should work well * in all circumstances (ie gives IO-bound processes good response etc)."
<Ermine>
> fails to compile with modern toolchains
<Ermine>
challenge accepted
[itchyjunk] has quit [Ping timeout: 248 seconds]
dennis95 has quit [Quit: Leaving]
[itchyjunk] has joined #osdev
skipwich has quit [Read error: Connection reset by peer]
skipwich has joined #osdev
<gog>
hi
* kazinsal
pets gog
* gog
prr
valshaped74248 has joined #osdev
valshaped7424 has quit [Read error: Connection reset by peer]
valshaped74248 is now known as valshaped7424
heat has quit [Remote host closed the connection]
heat has joined #osdev
agent314 has quit [Ping timeout: 245 seconds]
agent314 has joined #osdev
CaCode has quit [Quit: Leaving]
agent314 has quit [Ping timeout: 248 seconds]
agent314 has joined #osdev
agent314 has quit [Ping timeout: 256 seconds]
Yoofie6 has joined #osdev
Yoofie has quit [Ping timeout: 245 seconds]
Yoofie6 is now known as Yoofie
Hammdist has quit [Ping timeout: 246 seconds]
Burgundy has quit [Ping timeout: 248 seconds]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
Valeria22 has joined #osdev
<heat>
geist, i dont think so, I'm running under qemu KVM
<heat>
and the only thing real here (the ARM timer) is system register based
<geist>
kk
<geist>
thought you were having irq problems, which can sometimes be because GIC
<heat>
yeah but that GIC is emulated sooooooooooo
<heat>
right?
<heat>
(certainly have -trace gic working, so absolutely)
<geist>
it may be that uncached would still even affect KVM. would have to read from the Tome and ponder what happens with a cached mapping on top of a missing L2 page which KVM traps
<geist>
may be that the cpu may still be allowed say speculate into it or whatnot
<geist>
but yeah, probably not. probably just insta traps
<heat>
arm is herd
<heat>
:(
<geist>
yeah, more like x86 is magic so you dont have to think about it
<mjg>
fuck arm
<mjg>
or farm, for shor
<geist>
ARM exposes all the fun behind the curtain
<geist>
flip side is you get an exploit every other week on x86...
<heat>
i dont get the fun behind the curtain since effectively everyone does things the same way
<geist>
magic is hard
<heat>
yea but its not like ARM processors cant have these issues
<geist>
well, yes and no. there are lots of optimizations you can do, but it's not really for your (the software persons) benefit
<geist>
it just means less crap they have to implement in hardware
<geist>
with the idea that software needs to follow a long list of rules
<heat>
they can, and if they're not actively finding exploits, they're either not looking hard enough or conventional ARM cpus aren't that fancy yet
<geist>
well, the yes and no was for an earlier question
<heat>
yes
<geist>
not the arm processors cant have issues
<heat>
i know
<geist>
as far as arm processors having these problems, spectre like stuff sure, though i think a fair amount of the other retbleed/etc like things are kinda because x86 has more magic
<geist>
ie, vzeroupper, div by zero, etc are all things that are x86 specific
<geist>
because of silliness in the past
<heat>
dsbs and isbs, weakly ordered stuff and shit, i /kinda/ get it sometimes
<heat>
but things like setting ttbr needing serialization and explicit invalidation??
<geist>
sure, that's precisely what i'm talking about re: hardware doesn't have to implement it, because it's a software problem
<geist>
software has to do the same thing everywhere, but its still less hardware
<geist>
which was the goal
<geist>
ie, it's not for your benefit, as the software person
<zid>
gets in the way of them having a good high performance desktop style chip though imo, less hardware is less hardware to accelerate with and less to optimize
<mcrod>
hi
<geist>
it depends. in the case of say setting TTBR and it not serializing, that lets you delay the place where you sync the pipeline to after you've set a few control regs
<geist>
so it's technically a place for optimization
<geist>
TLB flushing is a great example of this: you can start a flush and then queue up a bunch of serialize after the fact
<zid>
x86 is sort of on the extreme other end and also misses optimizations
<zid>
cisc risc histories coming into play here
<geist>
but yeah it all depends on how you see it: for certain things (like say rep movs) it's great to tell hardware what you're doing so it can accellerate
<heat>
i think this is all a really selfish question anyway
<geist>
for other things like 'writing a series of control regs' it doesn't know why you are, so it is not good if hardware stops and syncs the world after every once
<zid>
You *could* tell an x86 what you're doing regarding your flush thing too, there just doesn't *happen* to be an instruction for it
<zid>
but they're slowly adding things like NT stores, different cache flushes, etc so that you can
<geist>
right, but if you did that you're back with ARM again: a two phase thing. write the thing, then sync with an instruction
<heat>
software people want complex hardware that's easy to work with, hardware people want simple hardware
<zid>
there isn't an ideology against it
<geist>
and oon the same thing arm is adding things like rep movsb, so it's all moving in the same direction :)
<heat>
x86 is the ideal architecture
<geist>
basically everything is arriving at the same result, it just takes a long time
<heat>
facts
<zid>
Most of the time you don't know *why* you're doing a thing, so there's no intent to signal
<zid>
so I think in the 'default' case, the x86 style probably wins
<heat>
i assume you need agressive macro-op fusing to get x86-ish performance out of the bat
<geist>
annoyting thing: i have some device on my wifi that i dont know what it is
<heat>
and x86 already does intensive macro-op fusing
<geist>
so i'm trying to port scan the crap out of it to figure out what it is
<heat>
nmap doesn't tell you?
<zid>
MAC?
<geist>
it's not respionding to anything
<zid>
should at least give you the vendor
<geist>
i think it might be random
<geist>
it's not matching a particular vendor
<zid>
it's a ghost.
<heat>
tfw geist is trying to find out which one of the 3 billion devices he has is connected to the wifi
<zid>
router's haunted.
<heat>
it's your SPARC geist
<geist>
okay, good call, the vendor is google
<geist>
cc:a7:c1
<geist>
i betcha it's a google device doing a random mac address assignment, and thus isn't in my unifi database
<geist>
and it's (properly) not respoinding to *anything* on a port scan
<geist>
except ARP
<geist>
so i guess that's good
<geist>
heat: well, i dont have a billion devices, but i have 39 known ones
<zid>
google firestick tv dongle thingy
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<zid>
oh no, the ghost is hacking heat's router now
<zid>
someone firewall the gibson
<geist>
nah i'm sure it's omsehting i added, but i just like to go into the unifi database and add a name to every known thing
<zid>
did you add a hockey puck hanging off a hdmi cable to your TV by any chance? :P
<heat>
work thing?
<heat>
my router shows me the DHCP-given hostname for most devices that connect
<zid>
he's secretly got a new android
<geist>
not a work thing, i have a separate wifi network and vlan for that
<zid>
one of the prototypes with stickers that say not to show anybody
<heat>
INTEL CONFIDENTIAL
<geist>
watching the port scan with tcpdump, a few tcp ports are responding with RST, so i think there will be some sort of report when it finishes