elastic_dog has quit [Killed (mercury.libera.chat (Nickname regained by services))]
elastic_dog has joined #osdev
averymt has joined #osdev
gog has quit [Ping timeout: 250 seconds]
averymt has quit [Quit: Leaving]
<zid>
sakasama: My favourite part is the rocks
<zid>
I'm sure they're culturally significant somehow, but it's just funny to me
<zid>
we have darwin, they have rocks
<zid>
and a cow
<sakasama>
I suspect most rural people would much rather have a cow and rocks than a Darwin.
FreeFull has quit []
[itchyjunk] has quit [Read error: Connection reset by peer]
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #osdev
Burgundy has joined #osdev
TkTech9 has joined #osdev
TkTech has quit [Ping timeout: 240 seconds]
TkTech9 is now known as TkTech
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
xenos1984 has quit [Quit: Leaving.]
Burgundy has quit [Ping timeout: 240 seconds]
heat has quit [Ping timeout: 240 seconds]
heat has joined #osdev
frkazoid333 has quit [Read error: Connection reset by peer]
frkazoid333 has joined #osdev
pmaz has joined #osdev
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #osdev
bgs has joined #osdev
terminalpusher has joined #osdev
Gooberpatrol66 has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
pmaz has quit [Ping timeout: 256 seconds]
<mjg>
kazinsal: the guy who played daniels passed away
<mjg>
i just learned
<kazinsal>
yeah, about a month back
<kazinsal>
real sad shit
<kazinsal>
was in the middle of a rewatch of Bosch at the time, which he's also got a lead role in
<mjg>
heh
<mjg>
i learned by accident. youtube shorts recommended a shitty scene from "young sheldon" and he was there
<mjg>
top comment was RIP :X
goliath has joined #osdev
xenos1984 has joined #osdev
slidercrank has joined #osdev
slidercrank has quit [Max SendQ exceeded]
slidercrank has joined #osdev
bgs has quit [Remote host closed the connection]
<ddevault>
bleh. I have to write a GDT & IDT in my bootloader
<ddevault>
I had hoped very much to avoid this
biblio has joined #osdev
Irvise_ has quit [Quit: Bridge terminating on SIGTERM]
sakasama has quit [Quit: Bridge terminating on SIGTERM]
raggi has quit [Quit: Bridge terminating on SIGTERM]
selfsigned has quit [Quit: Bridge terminating on SIGTERM]
junon has quit [Quit: Bridge terminating on SIGTERM]
kivikakk has quit [Quit: Bridge terminating on SIGTERM]
ia64developer has quit [Quit: Bridge terminating on SIGTERM]
benwaffle has quit [Quit: Bridge terminating on SIGTERM]
chibill has quit [Quit: Bridge terminating on SIGTERM]
pounce has quit [Ping timeout: 256 seconds]
pounce has joined #osdev
pmaz has joined #osdev
<ddevault>
whelp, I just realized that a GDT/IDT is probably going to do little to help me
<ddevault>
if it triple faults when I load new page tables I'm guessing that no amount of IDT will save me if the ISRs are fucked, too
<ddevault>
back to square zero
<kazinsal>
so long as your IDTR points to a valid linear address then yeah you get to deal with the fun of a page fault causing a TLB lookup and subsequent miss and page table dereference
<ddevault>
though it's possible that the page tables are not actually fucked up? being optimistic here
<ddevault>
works on qemu softmmu, triple faults on KVM and (some) real hardware
<ddevault>
so it could be a red herring that writing to cr3 causes it
<kazinsal>
could be you're writing to a reserved bit -- often softmmu implementations just ignore writes to reserved instead of causing a fault
<ddevault>
reserved bit of...?
<ddevault>
cr3? no, I don't think so, I'm writing a physical address aligned to a page
<ddevault>
I also think the page table entries are all in order
<klange>
What environment are you setting up, and where are you coming from?
<ddevault>
I'm a UEFI application
<ddevault>
I am setting up my own page tables which have the lower half identity mapped same as before
danilogondolfo has joined #osdev
<ddevault>
EFI implementation is OVMF/edk2
<ddevault>
softmmu works, reset on KVM after writing cr3
<ddevault>
interrupts are disabled
<klange>
Hopefully silly question, but 32-bit or 64?
<ddevault>
no other modifications to the environment
<ddevault>
64
<klange>
Okay, good - 32-bit EFI can be weird since the way identity mapping is set up is undefined (could be no paging, could be normal paging, could be PAE) - at least for 64-bit you should know what you're in for (until I learn that some recent 10th+ gen intel chipsets are shipping with an EFI firmware that uses 5-level paging for its identity mapping...)
<klange>
Hm, are you doing anything funny with large page sizes?
<ddevault>
fucking gcc, too goddamn smart for your own good
<ddevault>
hmm
<ddevault>
it is possible that this only fails on AMD
heat has quit [Remote host closed the connection]
heat has joined #osdev
* ddevault
wails, gnashes teeth
<kazinsal>
the important mantra of x86 osdev: "the system is deterministic; you're just doing something wrong"
<mjg>
osdev as in this channel or in general
<mjg>
:]
<kazinsal>
in general
<mjg>
is this what they think on discord?
<kazinsal>
I think in the discord they're more wondering why their mangled registers are causing the BIOS to trash their system state
<kazinsal>
one of the fun things about occasionally breaking to fiddle with something like a 5150 is knowing exactly how the guts of the system works from firmware all the way down to individual ICs
<mjg>
i don't know if "works" and "firmware" in the same sentence adds up mate
<mjg>
firmware is fucking webdev-quality, i don't know how they do it
<kazinsal>
it adds up when the firmware hasn't changed since 1982!
<kazinsal>
especially when the assembly source for it was listed in the manual that came with the computer
sakasama has joined #osdev
pmaz has quit [Ping timeout: 240 seconds]
pmaz has joined #osdev
<geist>
yeah totally. old computers are comforting for this sort of thing
<mrvn>
ddevault: that memset should be unneeded since the tables are in .bss. I think your __asm__ needs a memory clobber and/or volatile.
<kazinsal>
reminds me, I gotta line up a series of machines to buy so I can do a trip down to seattle this summer and roll back through the border going "no sir I definitely did not just buy two grand in vintage computers and typewriters sir"
<ddevault>
right re: memset
<ddevault>
though this is COFF which I'm less familiar with and am using poor tooling for so I dunno how much I can rely on bss
<ddevault>
lemme try improving that asm code
<mrvn>
ddevault: isn't your boot.S code zeroing .bss and runing the initarray?
<ddevault>
this is an EFI application, the loader should be zeroing bss
<ddevault>
but yeah, I'm being silly, bss is definitely zeroed
<mrvn>
Also "cli"? 1) if interrupts are enabled before MMU they will probably trippel fault due to all the addresses being wrong. 2) if interrupts are enabled now they suddenly aren't. You aren't restoring them.
<ddevault>
anyway, did my asm need volatile and "memory" clobber? yes. did it help? no :(
<ddevault>
this is EFI man
<ddevault>
do you grok the EFI environment? these assumptions are wrong
Irvise_ has joined #osdev
raggi has joined #osdev
kivikakk has joined #osdev
nyah has joined #osdev
gog has joined #osdev
<mrvn>
ddevault: running cli without matching sti or push/pop never makes sense
<ddevault>
duly noted
<mrvn>
"Identity maps the first 1GiB of physical memory at -1GiB for the kernel image in conventional memory in the low 1 MiB physical address space." parse error. that sentence makes no sense
<ddevault>
the first gig of physical memory is mapped to the last gig of virtual memory
<mrvn>
how is that in the low 1MiB physical address space?
<ddevault>
the kernel image is stored in the first MiB of physical memory, where there is always some conventional memory hanging about
bauen1 has quit [Ping timeout: 268 seconds]
<ddevault>
regardless of the physical memory layout of the remainder of the system
GeDaMo has joined #osdev
<mrvn>
And where are you actualy doing that mapping? In the code I only see the 64GiB mapping. There is no extra loop to map 1GiB. And the EFI environment identity map "perserving" doesn't look like it does any preserving to me. It just points the pml4[0] to a zeroed out page table.
<mrvn>
ups, no the 64GiB mapping initialized the pdpt[0] for that.
<ddevault>
yeah
<ddevault>
the first 1G mapped to -1G is set up on 30
<ddevault>
line 30*
<ddevault>
which is a zeroed page table... until the first iteration of the loop on line 31
chibill has joined #osdev
selfsigned has joined #osdev
<mrvn>
ddevault: right. that gets lost a bit with the loop.
<ddevault>
as for interrupts, this is a bootloader
<ddevault>
from this point on they are to be left disabled until the kernel proper enables them at its leisure
<mrvn>
When I read the code I see "Identity mape the first 64GB..." Ok, that's the 3 for loops there. "Identity maps the first 1GiB ..." No, no code for that after the for loops.
<ddevault>
yeah, that code could be clearer.
<mrvn>
It's easier to read when the comment is in the same order as the code.
* gog
loops
junon has joined #osdev
<mrvn>
and I would just remove the "for the kernel image in conventional memory in the low 1 MiB physical address space.
<mrvn>
I can't even believe it's true that efi loads the kernel into the first 1MiB. What if the kernel is larger than 1MiB?
<ddevault>
EFI doesn't load the kernel in the first 1MiB
<ddevault>
/my bootloader/ does this
<ddevault>
which is what this code is
<gog>
EFI you can technically put it anywhere it lets you allocate a fixed address
<gog>
provided there's enough room
<ddevault>
to be clear, what we're looking at here is
<ddevault>
the EFI firmware (edk2) loads this code from a PE32+/COFF executable, PIC, wherever it feels like; this is a UEFI application running in the standard UEFI environment for x86_64
<mrvn>
Usualy you put the kernel at 0x100000 and leave the first MiB alone because there is all sorts of legacy cruft in there you don't want to overwrite.
<ddevault>
this application is my bootloader, it reads the kernel from the EFI boot device as an ELF file and drops it into memory, sets up a higher half address space, then yeets EFI and jumps to the kernel
<mrvn>
line 24 I think also belongs at line 35
<ddevault>
yeah, I intend to move the kernel, but I have ruled the location out as the cause of this grief
<ddevault>
nah, line 24 is also relevant for the 64GiB mapping
<mrvn>
true. never mind.
<ddevault>
anyway, the specific issue is that this file is supposed to set up the address space we need for the higher half kernel. this code is running in the lower half, identity mapped, and so it preserves that on line 38
<mrvn>
anyway. the only relevant thing should be pml4[0]
<ddevault>
this works on qemu softmmu, and on some hardware, but the cr3 write triple faults on my KVM and on my test hardware
<mrvn>
pdpt decays to the address of the array. "&pdpt" is confusing.
<ddevault>
nack
<mrvn>
The execute bit on x86 is inverted (NX), right?
<ddevault>
correct
<mrvn>
PDE_PS means 2MB page?
<ddevault>
yes
<ddevault>
worth reiterating that this works on some configurations and not others
<mrvn>
Everything is present, writable, exeutable, global. Looks fine.
<ddevault>
if it was something wrong with the page table itself, it would probably fail on all configurations
<mrvn>
ARe you sure it's not some bit in the other control registers that's messed up?
<ddevault>
that'd be my assumption
<ddevault>
I reviewed the likely suspects and didn't spot anything, lemme share...
<mrvn>
If it works only in qemu then most likely it's some cache effect.
<ddevault>
it also works on some real hardware
gog has quit [Quit: byee]
<ddevault>
and in any case writing to cr3 blows away the TLB
<ddevault>
control registers all identical to working configuration (qemu softmmu)
warlock has quit [Quit: Lost terminal]
heat has quit [Remote host closed the connection]
heat has joined #osdev
raggi has left #osdev [#osdev]
<mrvn>
must be something simple you will hit yourself for forgetting
terminalpusher has quit [Ping timeout: 245 seconds]
dayimproper has joined #osdev
<Ermine>
Does gdb work in efi?
<ddevault>
kind of
<ddevault>
PIC and no symbols makes it a mess
<ddevault>
but I can get a debugger in here and poke around with some degree of annoyance
<Ermine>
I tried too, but got only addresses. These are indeed harsh conditions
<Ermine>
Also I'm think I used wrong ovmf image
<ddevault>
volatile int s = 1;
<ddevault>
while (s);
<ddevault>
"breakpoint"
<moon-child>
__asm__ volatile("int3")
<Ermine>
No real breakpoints? That really sucks
<ddevault>
I mean you can set breakpoints if you know what address to use
<ddevault>
but therein lies the problem
<ddevault>
and int3 does not work in KVM fyi
<ddevault>
I mean it does but it doesn't break out of kvm_run
<moon-child>
huh, p sure it's worked for me before
<moon-child>
or, hmmm, no, I think I might have been using qemu under freebsd at that point, so would have been software emulation
<Ermine>
Heck
sinvet has quit [Remote host closed the connection]
xenos1984 has quit [Quit: Leaving.]
wlemuel has joined #osdev
dayimproper has quit [Ping timeout: 265 seconds]
dayimproper has joined #osdev
bauen1 has joined #osdev
Burgundy has joined #osdev
pmaz has quit [Ping timeout: 260 seconds]
dayimproper has quit [Ping timeout: 265 seconds]
gog has joined #osdev
biblio has quit [Quit: Leaving]
xenos1984 has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
wlemuel has quit [Quit: Ping timeout (120 seconds)]
wlemuel has joined #osdev
xenos1984 has joined #osdev
vdamewood has quit [Ping timeout: 248 seconds]
Left_Turn has joined #osdev
awita has joined #osdev
slidercrank has quit [Ping timeout: 256 seconds]
novasharper has joined #osdev
slidercrank has joined #osdev
awita has quit [Ping timeout: 265 seconds]
[itchyjunk] has joined #osdev
vdamewood has joined #osdev
bauen1 has quit [Ping timeout: 246 seconds]
bauen1 has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
ptrc has quit [Remote host closed the connection]
ptrc has joined #osdev
goliath has quit [Quit: SIGSEGV]
dude12312414 has joined #osdev
bauen1 has quit [Ping timeout: 240 seconds]
bauen1 has joined #osdev
elastic_dog is now known as Guest2898
Guest2898 has quit [Ping timeout: 256 seconds]
elastic_dog has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
<Ermine>
Hmmm, $distro doesn't provide OVMF.fd, but there are OVMF_CODE and OVMF_VARS . Can I use them?
<heat>
yes
<heat>
iirc -bios OVMF_CODE.fd Just Works, but then you still have no vars. usually you copy vars into your local workspace or whatever and use drive if=pflash to setup shit
slidercrank has quit [Ping timeout: 246 seconds]
<Ermine>
heat: thank you
<heat>
np
zaquest has quit [Remote host closed the connection]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
wlemuel has quit [Ping timeout: 246 seconds]
wlemuel has joined #osdev
zaquest has joined #osdev
slidercrank has joined #osdev
Ali_A has joined #osdev
slidercrank has quit [Read error: Connection reset by peer]
<mjg>
so i just found out that the magical linux scheduler kind of suckkkz
innegatives has joined #osdev
<mjg>
in ways shared with the freebsd one
<mjg>
namely it makes processes wander around the machine very easily
<mjg>
if they go off cpu
<innegatives>
If you do a short jump on x86 with diff of +2, is it basically no-op? Or does starting address get calculated after the jmp instruction itself, so its like skipping 2 bytes?
<zid>
yea jmp +2 is a nop
<zid>
(a complicated nop)
<zid>
jmp -2 is an infinite loop
<mjg>
you mean in terms of cost?
terminalpusher has joined #osdev
<mjg>
watcha doin'
<innegatives>
me?
<mjg>
zid
<zid>
Implementing a tree
<heat>
mjg, linux kernal
<zid>
I already said
<heat>
best operating!!!!
<zid>
Need it for some blast processing
<mjg>
heat: you know which os does not have that problem, at least for the test case at hand?
<mjg>
heat: dflybsd :O
<heat>
SCHECKMATE!!!!!!!!
<mjg>
WHAT NOW MOTHERFU^W^W^Winteresting result
<innegatives>
ndisasm says "1110101100000010" is "jmp short 0x4". Why 0x4 tho? Isn't "00000010" just 0x2?
<zid>
what's that in hex
<zid>
so I can actually look at it
<heat>
mjg, ok so freebsd supports x86 57-bit address spaces right?
<heat>
I think 13 or 14 got that? somewhere around 2020
<innegatives>
zid: EB02
<zid>
yea the 0 point is the end of the instruction in the encoding space by the looks of it indeed
<zid>
assemblers and other jumps and other cpus all act kinda differently
<mjg>
heat: it has code to do it but afair to failed to boot on real hw :d
<zid>
(most assemblers don't even support immediate relative jump)
<innegatives>
zid: i dont understand what you mean
<mjg>
windows is liek the last system i would expect to do it
<heat>
if firmware enables PML5, any operating system that does not support it will crash and burn
<heat>
windows is the first system I would expect would support it, because efi people almost exclusively test on windows
<heat>
windows boots? 🚢 it!!
<mjg>
maybe they are also testing without the hw? :O
innegatives has quit [Quit: WeeChat 3.8]
bauen1 has quit [Ping timeout: 240 seconds]
<heat>
that would've been excessively funny, yes
* mjg
burps
<sham1>
ew
<mjg>
people tend to have an idea that if someone does something, they have a reason
<heat>
they should've used cr3 for this... no need to muck around
<mjg>
good or bad, but they have one
<heat>
if cr3 had been used (like the top bit or whatever), this would work in a backwards compatible way, always
<mjg>
however, practice shows that if an action looks stupid, it probably is
<heat>
also, it turns out this is also a problem in ARM
<zid>
ARM is a problem on ARM
<zid>
They should try being x86 it's easier
<heat>
ia64 is ezpz
<heat>
until mjg the evil man tries to kill it
gog has joined #osdev
<mjg>
did they restore that shite?
<heat>
i don't think they ever pushed it
<heat>
because torvalds has feelings
<zid>
I too
bauen1 has joined #osdev
<gog>
hi
slidercrank has joined #osdev
Gooberpatrol66 has quit [Remote host closed the connection]
Gooberpatrol66 has joined #osdev
<sakasama>
lo
dayimproper has joined #osdev
wlemuel has quit [Quit: Ping timeout (120 seconds)]
wlemuel has joined #osdev
* geist
yawns
<geist>
hi
* geist
force pets everyone
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<GeDaMo>
Are you a Jedi or a Sith? :|
<heat>
hi geist
<geist>
hi heat
<mjg>
git push --dark-side
<heat>
now that i'm on this, fuchsia doesn't have pml5 support right?
<geist>
nein
<heat>
yeah
<heat>
i figured
<geist>
i forget where it showed up in intel client
<heat>
anyway now I'm adding it to my OS because I'm a maniac
<geist>
did ryzen 4 pick it up?
<Ermine>
pml5 = page map level 5?
<geist>
sure. seems reasonable
<heat>
Ermine, yep
<geist>
of course i dislike that it's effectively a global decision
<heat>
i dislike that its a cr4 bit and not a cr3 bit
<geist>
right, there's no functional way to toggle back and forth
<heat>
cr3 bit would make it backwards compatible even
<geist>
with riscv you could reload satp and switch modes at the same time. though to keep the kernel mapped in both universes would require a little bit of trickery
<heat>
the problem I've been digging thru is that intel firmware people are trying to add PML5 support to EFI... which will break booting for everyone else
<geist>
and obviously arm64 has a ultimately flexible solution there
<heat>
arm64 apparently suffers from a similar problem too
<geist>
yah that seems insane. obviously the next stage OS could drop out of MMU, load a 4 level table, but that requires support
<heat>
yeah and will break everyone that didn't know this. EFI spec just says "paging enabled"
<geist>
you sure? I thought it was kinda explicit here
<zid>
I think their solution is probably correct tbh
<heat>
for x86_64? yes
<geist>
yay underspecification
<heat>
the aarch64 section is more explicit, but still not enough
<geist>
but otoh you can just drop out of paging on x86 immediately
<heat>
like, it doesn't specify T0SZ
<geist>
riscv probably just doesn't start paging
<heat>
arm64 efi firmware may put ACPI tables, etc up there in 50-something bit space. now you're fucked because you can't map ACPI tables
<geist>
sure, but then just dont do that
<heat>
yeah but efi always allocated top-down
<heat>
so :))))))))
* geist
shrugs
<geist>
ythat's already like 3 levels of what ifs there
<geist>
what matters is does windows boot or not
<geist>
all other issues are secondary or irrelevant
<heat>
AMEN
<heat>
thinkin like a true firmware dev
<heat>
answer: no, it does not support pml5
<heat>
i had a guy suggest that I could just disable pml5 in my virtual machine if I wanted to boot my operating system museum... dawg only linux supports that shit
<geist>
on a different note i just got SMP working again on fuchsia yesterday
<geist>
yay
<geist>
on riscv
<zid>
I don't have a problem at all. If hw supports pml5, and you install a modern bootrom, efi sets up pml5, and kernel needs to be new enough to support pml5. This is going to be 'obscure server boards' for the next 20 years.
<heat>
yay
<geist>
zid: well, i think its in all the newer client hardware now, but i can't tell you precisely when
<heat>
zid, i think intel client cpus support it already
<geist>
probably 12th gen?
<geist>
zen4 i think picked it up too
<heat>
yeah probably 12th
<zid>
By a time a user actually sees it
<zid>
it will be 20 years afterwards
<geist>
disagree, if MSFT gets their way
<zid>
pml5 is already like on its 5th birthday :p
<geist>
yeah but client hardware
<heat>
no, pml5 is even older. 2016
<geist>
i await FRED
<geist>
come save us FRED!
Ali_A has joined #osdev
<zid>
(Like, kernels older than your hw never work, because of your ethernet driver anyway)
<heat>
"Heap spraying can only occur when the kernel contains security vulnerabilities, and if there is no known ways of performing such an attack, then we would simply be paying a consistent cost."
<heat>
this guy is based
<heat>
getting pwned? lol just have no bugs
* gog
sprays
<bnchs>
spays
<zid>
hardening should be optional imo
<heat>
thats why linux has .config
<zid>
assuming it has a CONFIG_ yea
<heat>
it does
<zid>
all good then, carry on
bauen1 has quit [Ping timeout: 240 seconds]
Ali_A has quit [Ping timeout: 245 seconds]
frkazoid333 has quit [Ping timeout: 256 seconds]
awita has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 264 seconds]
frkzoid has joined #osdev
dayimproper has quit [Ping timeout: 265 seconds]
tiggster has joined #osdev
tanto has quit [Quit: Adios]
pie_ has quit []
vancz has quit []
vancz has joined #osdev
slidercrank has quit [Ping timeout: 240 seconds]
innegatives has joined #osdev
<innegatives>
Is indirect intersegment jump on x86 undefined for when modr/m points to a register?
<geist>
geezus these are some pretty specific questions
<innegatives>
NASM just spits out some crap with db when given that
<geist>
as as always, what does the manual say?
vancz has quit [Ping timeout: 264 seconds]
<geist>
but really i'm just being picky, these are highly specific questions, i'm not sure anyone here groks x86 at that level
<geist>
generally i'd look in the instruction listings in the intel manual and they'll probably list all the valid forms
<geist>
i'd generally assume the forms not listed are undefined
<jimbzy>
I can't even spell 'y75'.
<geist>
but then it's x86. there are probably thousands of these sort of unwritten 'maybe works maybe not, have to check real hardware' sort of things. welcome to writing x86
<geist>
that's even a though one to write a test case for
<GeDaMo>
Also, there's an ##asm channel
<geist>
yah that listing would tend to indicate that far jumps are only absolute
<innegatives>
what does absolute stand for?
<geist>
fixed addrss
<innegatives>
but it clearly says modr/m as well
<geist>
but not in the far case
<geist>
those are near jumps it lists the r/m
<innegatives>
FF /5 JMP m16:16 M Valid Valid Jump far, absolute indirect, address given in m16:16
<innegatives>
M stands for modr/m
<geist>
okay, so then guess it works <shrug>
<geist>
try it and see
<geist>
i mean this is some real minutae, you're kinda on your own here
<geist>
this is also precisely why i hae absolutely zero interest in writing an x86 emulator. sounds like a bunch of un-fun minutae. sometimes thats fun, but only up to a point
<innegatives>
but imagine running Doom on MS/DOS
<geist>
i assumed `r/m32` was the short for mod r/m
<geist>
but i guess it's not. probably register or 32bit immediate?
<zid>
ea
<zid>
yea
<zid>
reg or [mem]
<GeDaMo>
I've run Doom on MS-DOS, I don't have to imagine it :|
<jimbzy>
We lived it...
<zid>
I mean, I'd find this fun, but I'd just be reading references and testing stuff, not blocking on having to slowly ask questions of people who aren't motivated to respond by anything
<zid>
that'd be annoying and boring
tanto has joined #osdev
pie_ has joined #osdev
<zid>
I like writing emulators though
tanto has quit [Client Quit]
pie_ has quit [Client Quit]
tanto has joined #osdev
vancz has joined #osdev
pie_ has joined #osdev
<geist>
yah was gonna say, what's so interesting about doom on ms-dos? it ran on msdos originally...
<innegatives>
i mean on an emulator
<GeDaMo>
Like DOSBox?
<geist>
and there are tons of x86 emulators already, so if that's your goal it's already done. of course if your goal is to write an emulator because you want to, i totally approve
<geist>
doom has all the 32bit extension stuff too, so that'll be fun, emulating all that
<zid>
I need to write that x86 emulator for x86
<geist>
and the ugly mode switches
<zid>
so I can run my vga bios in long mode
tanto has quit [Client Quit]
pie_ has quit [Client Quit]
vancz has quit [Client Quit]
tanto has joined #osdev
pie_ has joined #osdev
vancz has joined #osdev
<geist>
yah like i said if you wwant to write an x86 emulator for fun, go for it, but if you want it to do a specific thing, i think there are enough of those that already exist that you can probably do
<geist>
since x86 emulation is such a hairy mess, it's probably not worth the effort for one task
<geist>
vs sayt riscv or something which you can write before lunch
<innegatives>
What is the difference between jmp [bx] and jmp bx?
<zid>
a dereference
<innegatives>
Oh, so bx means just the address at register, [bx] means address at address at register?
<zid>
that is what [] means
<zid>
and has meant for the *weeks* you've been reading the manual >_<
<FireFly>
surely the manual defines what [] means somewhere?
<geist>
side note there was some discussion about The Discord last night. are folks here generally hanging out on the osdev discord i'm thinking of?
<geist>
ie, did it... get better?
<jimbzy>
Aww. I didn't win the scope I was bidding on :(
<zid>
Win me one too while you're at it
Left_Turn has joined #osdev
<jimbzy>
I'm probably going to just save up and buy a Rigol.
<jimbzy>
I have a feeling collectors are snapping up all the older Teks.
<bslsk05>
www.ebay.co.uk: Vintage Tektronix 465 100MHz Oscilloscope with Manuals Extras - Tested to Power | eBay
<jimbzy>
I'm actually shocked I haven't been able to find one locally. There are like 8 universities and colleges within a 60km radius.
<zid>
I assume they get used until they die more often than not, a 200MHz scope with a couple of channels is more than plenty for 99% of useages
<zid>
rather than replaced every few years
<zid>
with newer models
<jimbzy>
I'm going to check with the local ham club and see if anyone has anything available, too.
<zid>
I wanna try one of those crappy usb dongle ones
<zid>
where they're just like.. composite video capture chips and a tiny bit of buffer memory and a usb controller
<zid>
for a couple dollars
<jimbzy>
Whatever works. :P
<zid>
good enough for seeing if random chips are wiggling and not just pinned high or low with a multimeter
<zid>
which is 90% of what a lot of people need a scope for
<jimbzy>
Get one and try it out.
<zid>
No no this whole conversation was about you getitng me on, can't gaslight me
<geist>
i've been pretty happy with my rigol
<geist>
really there are lots of pretty good fairly cheap new digital scopes at the low end, most of the differentiation is the software and how infuriating it is
<heat>
<geist> side note there was some discussion about The Discord last night. are folks here generally hanging out on the osdev discord i'm thinking of? <-- I don't think so?
<zid>
I couldn't tell you, not being there
<geist>
oh kazinsal i think was mentinoing it
<zid>
(I got banned in 3 mins flat, RTA WR)
<geist>
was just curious if folks are generally migrating there, etc
<geist>
and maybe it got less, uh, problematic
<geist>
it was problematic directly proportional to how much of an opinion you had about any particular topic
<geist>
and whether or not that intersected with The Management
<jimbzy>
Yeah, I'll find something eventually.
<zid>
I had "an" opinion, which is 100%
<zid>
so it was 100% problematic, math checks out
<kazinsal>
I don't know if it's still that way but it doesn't seem to be particularly interesting conversation wise
<geist>
correct. i did too, though of course i didn't push it as hard as you would, so i lasted a few more days :)
<geist>
yah i was trying to raise the level of discourse a bit, but alas.
<zid>
I'm a power top
<zid>
(is that a thing?)
<geist>
kinda topping from below
<heat>
i think tops are implicitly power?
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<bslsk05>
'Power Shovel (PS1 Gameplay) | Obscure Games #21' by NeoGamer - The Video Game Archive (00:04:23)
<geist>
reminds me of Tiny Tank
<geist>
i mean not directly, but thinking of old PS1 games i think of Tiny Tank which i played the crap out of
<innegatives>
Is impl of CALL instruction exactly same as JMP, with just "PUSH address + insn_size" added? There's nothing else to it, right?
<heat>
who knows what an x86 instruction would do!
<heat>
most definitely not the intel architecture software developer manual
<zid>
I thought it turned your spit green
<innegatives>
CALL doesn't push CS, right? Only IP + insn_size?
<heat>
<heat> who knows what an x86 instruction would do!
<heat>
<heat> most definitely not the intel architecture software developer manual
<zid>
This is kinda weird btw, writing an emulator for a cpu you can't even use
<heat>
yeah the 8086 was ageeeeeeeeees ago, nobody uses that anymore
<zid>
This is sort of like trying to follow the ikea instructions in swedish
tiggster has quit [Remote host closed the connection]
<heat>
you try to follow those things?
<heat>
I just call ikea directly, much easier
<zid>
heat pays for the young lad to assemble it for him, so he can watch
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
awita has quit [Ping timeout: 240 seconds]
danilogondolfo has quit [Quit: Leaving]
xenos1984 has quit [Read error: Connection reset by peer]
innegatives has quit [Quit: WeeChat 3.8]
xenos1984 has joined #osdev
<mrvn>
zid: Just use the x86 emulator from xfree86
<mrvn>
zid: They had that to initialize graphics cards on alpha by emulating the bios.
Turn_Left has joined #osdev
Burgundy has quit [Ping timeout: 264 seconds]
goliath has joined #osdev
Left_Turn has quit [Ping timeout: 264 seconds]
<moon-child>
lmao what
<heat>
zid's giving away my secrets :(
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 264 seconds]
<gog>
hi
<heat>
gorg
CalculusCats has quit [Quit: Goodnight...we love you all]
<zid>
I can hear a fox
<zid>
I hope my cat isn't dumb enough to fight it
xenos1984 has quit [Quit: Leaving.]
CalculusCats has joined #osdev
nyah has quit [Quit: leaving]
bauen1 has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
<Bitweasil>
What's it say? ;)
<Bitweasil>
We lose a property cat every few years to probably coyotes, maybe great horned owls.
<Bitweasil>
Our last one was a big loss, it was a little thing, but a properly good hunter.
<heat>
today in annoying x86: i forgot shifts by a register mask by 0x1f
<Bitweasil>
Would come strutting across the driveway with its recent kill.
<Bitweasil>
Yeah... different architectures handle "shift amount > register width" differently, I think. :/
<Bitweasil>
Most won't let you do it in the immediate shift, but what they do with register shifts... *sigh*
<Bitweasil>
I will say, the ARM references are nice at that level because they're "Describe what to do to build it."
<Bitweasil>
Vs the x86 manuals are "This is what we did, at least as far as you need to know."
<heat>
yeah i was adding pml5 to my boot.S and I was like "why is PAGE_TABLE_INDEX giving me wrong indices"
<heat>
followed by 9 * 4 = 36 + ohhhhhhhhhhhhhhhhhhhh
<heat>
mind you, using shrdl, not shrl
<heat>
which sounds wrong to me but whatvs
rsjw has joined #osdev
<moon-child>
why's there shrdl but no etaoi
<moon-child>
definitely wrong
rsjw has left #osdev [#osdev]
<zid>
imagine doing a shl by cl
<zid>
is gas smart enough to warn about too big shift constants
<heat>
geist: on windows's PML5 support: "recent versions of Windows (I don't have exact versions) do support PML 5, both in the case if UEFI didn't use PML5, where you can tell Windows to switch to it via a BCD option, and in the case where UEFI did use it, Windows will continue to use it, with no option not to."
<heat>
this behavior probably screws everyone else by making vendors enable PML5 uefi support, which will break everyone else
<geist>
well, seems to be not really, because it can enable it if UEFI didn't right?
awita has joined #osdev
<heat>
yes, it can, but IMO the obvious observation will be "oh, windows only works if PML5 is enabled in firmware, lets leave that enabled"
<heat>
particularly as this is not documented anywhere
<geist>
Bitweasil: oh god, what does the fox say. i hadn't thought of this in years
awita has quit [Remote host closed the connection]
<geist>
heat: but honestly it really shouldn't matter much right? you get haded off from UEFI on x86, probably first thing you do is turn off the mmu, then reenable it with your page tables anyway
<geist>
doing a direct switch of the cr3 without at least validating the state is probably a bad idea
biblio has quit [Quit: Leaving]
<heat>
I asked the microsoft firmware team, and this is more or less paraphrased from the kernel team
<geist>
and yuo probably slam your own value of CR4 in it anyway
<heat>
no, it probably does matter, lots of OSes never leave 64-bit mode
<heat>
so 1) if you overwrite CR4 there, boom, #GP
<heat>
2) if you don't overwrite CR4 and just load your CR3, boom, your 4-level page tables are secretly 5-level
<moon-child>
I want 3-level page tables
<moon-child>
512gb ought to be enough for everybody!
<heat>
and there's the fun problem where if EFI passes you ACPI tables, the system table, yadda yadda from up there in 50-something physical address space, and you somehow skipped all those problems and you're now using PML4, you can't touch em directly in a direct physical map
<heat>
and, erm, efi allocates top-down :p
<geist>
oooh yeah forgot you can't drop out of paging on long mode
<geist>
yeah that does suck doesn't it
<heat>
undoing everything here makes you drop out of everything instantly, which kind of goes against the idea of "hey! everything's setup for me, nice!"
hmmmm has quit [Quit: Leaving]
<heat>
zircon for instances does not seem to ever drop out, at least in the kernel proper
<heat>
i don't know if the efi bootloader is doing something there