valerius has quit [Killed (NickServ (GHOST command used by theophilus!~corvus@user/theophilus))]
josuedhg has quit [Quit: Client closed]
bzzt has quit [Server closed connection]
bzzt has joined #osdev
valerius_ has joined #osdev
<vdamewood>
FWIW, pronouncing J as English pronounces a consonental Y happens in every Germanic language except English, and every Slavic language that uses the Latin script.
SGautam has quit [Quit: Connection closed for inactivity]
KitsuWhooa has quit [Server closed connection]
KitsuWhooa has joined #osdev
FireFly has quit [Server closed connection]
FireFly has joined #osdev
<karenthedorf>
So intel docs say there's a `JMP m16:64` encoding. Why will no assembler I've tried emit it? Seems saner than lretq when I need to long jump.
<Mutabah>
I think that's `ljmp [mem_location]`?
<Mutabah>
or, `jmp far [mem_location]`
<heat>
saner how?
<heat>
it's literally the same
<heat>
lretq is ljmp (%rsp) with a stack adjustment along the way
<Mutabah>
tbh, I would say it's less sane
<Mutabah>
as you're telling the reader/cpu that you're returning - when you're actually not
<Mutabah>
It likely doesn't matter for a once-off at bootup, but it does likely confuse the branch predictor
<karenthedorf>
Doesn't fsck up the branch predictor or shadow stack. (But yes, probabally not relevant as a one off early in boot)
<heat>
lol
<heat>
seriously, immeasurable in the large scheme of things (booting and/or booting a secondary core)
<karenthedorf>
Yeah, it's funky anyway. It wants an absolute address (and selector) in a memory location, but I have no idea how to get that value into a register in the first place tbh.
gildasio1 has quit [Ping timeout: 260 seconds]
gildasio has joined #osdev
<karenthedorf>
While lret can take a relative address I think?
<karenthedorf>
appears to assemble to `mov %esi, %ds`
<kof673>
(skims backlog) <game engine> <os> <language> and these 3 are 1. the ___ proceeds from the ___... "it is the same bird" j/k but not really
<heat>
that makes more sense, still a little weird though
<karenthedorf>
I changed it to esi
<heat>
i always do mov %ax, %ds
<guideX>
I kind of have a handle on what programs are now, but where should they come from? kind of obvious answers, an app store, the web, idk what do you guys think
<karenthedorf>
Also I'm pushing %rdi when only %di would suffice.
<guideX>
maybe package managers
<sauce>
guideX: users should type them in from magazines
<karenthedorf>
heat: mov %ax, %ds also assembles to mov %eax, %ds
<guideX>
I was thinking, maybe this os, should expose the source code of every program alongside its visual representation
<guideX>
so the user can jump in and edit it
<kof673>
yes do that and work towards synthesis os :D
<karenthedorf>
I think there's only one valid encoding of "mov %gReg, %sReg"?
<karenthedorf>
So mov %ax, %ds and mov %rax, %ds both have encodings, there is no mov %eax, %ds in the intel manual. Lmao.
<karenthedorf>
gcc assembler just emits `mov %ax, %ds` (opcode 0x8E) but decompiles it to mov `%eax, %ds`
<karenthedorf>
Even if the original assembly specified %rax
<karenthedorf>
You can only force it to emit `mov %rax, %ds` byt saying `REX.W mov %rax, %ds`
obrien has quit [Remote host closed the connection]
leon has quit [Server closed connection]
leon has joined #osdev
<geist>
huh i wonder if that's a valid combination
<geist>
i guess it just ignores the rex in that case
<geist>
and/or what if you specify the top bit i the REX? does it let you move from r8 or whatnot?
<karenthedorf>
It's the correct encoding for `mov %rax, %ds` if that's what you're asking.
<geist>
hmm, actually that must be a two byte opcode, since 0x8e can't encode the source rg
<geist>
yeah, but REX has more bits than 'i'm just 64bit'
<karenthedorf>
Oh I haven't tried messing with the other bits. x86 instruction encoding is voodoo
<bslsk05>
www.sandpile.org: sandpile.org -- x86 architecture -- 1 byte opcodes
<geist>
which just says it's MOV Sw,Mw
<geist>
so i guess the rest of that must come from another byte?
<karenthedorf>
`48 ff 2c 24`
<geist>
unless AX is implied i guess
<karenthedorf>
You can move from registers other than az
<karenthedorf>
*ax
<geist>
ah, maybe moving from ax is the single byte, but otherwise it has to go to a multibyte ff one
<karenthedorf>
Let me find it in the manual again
<karenthedorf>
Disregard that, wrong instruction
<karenthedorf>
`48 8e de`
<geist>
ah now we're talking
<geist>
yeah the de is probably describing the two registers
<geist>
and the 48 is the rex prefix
<karenthedorf>
48 is REX.W, 8e is mov gReg->sReg and de is the weird register encoding I can't parse
<karenthedorf>
I'm guessing the 'useful' bit of adding the REX.W prefix is allowing you to mov from r11 and the like, because it just truncates the value anyway
<karenthedorf>
But I tried to handright a MOD R/M earlier with .byte and it didn't make much sense.
<geist>
yah the de doesn't quite line up, since that would to me tell me it's DX, DS
<karenthedorf>
*handwrite
<geist>
'de' that is
<karenthedorf>
Yeah, should be rsi, not rdx.
<geist>
ah yeah RSI
<geist>
but you see how the REX.R bit in that case escapes it out, basically adding a top bit to get you 4 bits of register encidong
<karenthedorf>
The opcode was `mov %rsi, %ds` sorry. was using %rax before then grabbed it out the disassmbly of my code without actualy stating I'd copied an example using %rsi.
<geist>
ah okay that perfectly lines up then
<geist>
a mystery solved
<karenthedorf>
Argh, brain, get out the OCD loop of wondering if it is better to push a 16-bit (correctly reflecting what is accessed by the cpu) or just push a 64-bit value (keeps the stack aligned to 64-bits, smaller instruction encoding). It doesn't matter.
<karenthedorf>
The cpu doesn't care, since the extra bits are all 0 anyway
<geist>
yah
<geist>
though the 32 may be smaller since no prefixes required
dostoyevsky2 has quit [Server closed connection]
<karenthedorf>
`push %edi` fails to assemble
dostoyevsky2 has joined #osdev
<geist>
that is really strange
<karenthedorf>
`push %rdi` is one byte, since I'm in long mode.
<geist>
oh yeah i guess so. that's a case where REX prefix *isn't* needed
<geist>
and the 16 bit verion probably uses 0x66
<karenthedorf>
`66 57` vs `57`
<karenthedorf>
So less code, better stack alignment... in return for briefly using 3 bytes of stack in a leaf function. Why am I worrying about this.
<karenthedorf>
Also looking at the weird and wacky encoding compilers pick for various sizes of NOP is interesting.
<zid>
There are no 16 bit pushes on amd64 btw
<zid>
or was it just 8 there wasn't, maybe, ignore me
brynet has quit [Server closed connection]
brynet has joined #osdev
<karenthedorf>
There appears to be no 32bit pushes in long mode. Nor 8 but. At least of the form "push register", I didn't try immediates.
<zid>
huh yea, no 32 and no 8
<zid>
I knew it was missing stuff, I was *not* expecting there to just.. be a gap
<karenthedorf>
Good old legacy stuff.
<karenthedorf>
In 32bit there was the 'default' if you didn't apply a prefix to the opcode, and a '16-bit override' prefix.
<zid>
that's all modes
<karenthedorf>
In 64bit, the default is not 64bit, but there's no 32-bit prefix
<karenthedorf>
*is now
<karenthedorf>
That's my understanding anyway
<zid>
66s and 67s just swap to the 'other' one, 64 is weird in that it has two
<zid>
so real mode could interact with eax by slapping on the prefix, and protected mode could interact with ax by slapping it on
<zid>
but long mode is weird and like, defaults to 32 some of the time, and needs the prefix to make it 64bit instead
<karenthedorf>
Yup. But 64bit is a mix of "defaults to 64bit, can slap size-override on for 16bit, there is no 32-bit" and "defaults to 32bit, can slap the size-override prefix on for 16bit, or REX.W for 64 bit"
<zid>
yup, fun fun
<karenthedorf>
Bring on that project intel floated of nuking all the legacy crap from x64.
<zid>
they're eventually removing real mode with x86s
<zid>
won't be for a LONG time though
<zid>
it isn't going to change how anything works though
<zid>
you'll just.. stop being able to disable bits in cr2/cr4 to get back there
<karenthedorf>
Yeah, nuking real mode and the legacy pic and some other stuff iirc. It's a bootstrap paradox though, because no OS will boot on such hardware, and the hardware is useless without an OS to run on it.
<karenthedorf>
no current OS will boot*
<zid>
uefi is already a thing
<zid>
so every os will currently boot
<zid>
it breaks bootable cd-roms only, more or less
<zid>
and x86s will certainly be xeon only when it launches in 2030, and not be in consumer chips until 2040 or whatever, so it's not really going to matter if you can't boot a cd-rom on it
<karenthedorf>
I think there's a problem booting secondary cores/cpus without OS changes?
<kazinsal>
considering the shitfest that is the last two core generations I would expect that intel will never manage to do a widespread release of x86-S
<zid>
depends if you're amd or intel in that regard I think
<zid>
and all this will be sorted out in literal days, years in advance anyway
<karenthedorf>
Intel's white paper seems to prepare for that, adding a 64-bit startup IPI as a separate feature which can presumably appear a generation or two earlier.
<zid>
I think coreboot already has x86s whitepaper support
<karenthedorf>
I do wonder how much smaller in terms of die area/transistor count an x86s chip would be.
<zid>
The thing is, intel has to test all this shit, and they test it on linux, then just upstream any of the changes they make, years before the chips are even available
<zid>
0.01%
<zid>
at best
<zid>
It's mainly just to they have less test area, it's a mulitplier to everything else
<zid>
"did we break interrupts with this change?" "Okay but what about in ring -1" "okay but what about in protected mode with an invalid selector" "okay but what about in real mode" etc
dinkelhacker has quit [Server closed connection]
dinkelhacker has joined #osdev
<zid>
without real mode or ring0 protected mode, a lot of testing gets a lot quicker
<karenthedorf>
And chance for bugs, like that one where you could remap one of the PICs over SMM memory and escalate to ring -2. Can't do something similar if support that hardware doesn't exist any more.
<karenthedorf>
Can't remember if that was the lapic or the 8259 PIC
<zid>
lapic
<zid>
it had an MSR base address that was unchecked
<zid>
8259 doesn't have a memory interface at all
<karenthedorf>
x86s' 'removed features' list is a nice list of things I can just *never implement support for* in my own OS.
<zid>
tbh you shouldn't anyway, in $CURYEAR
<karenthedorf>
That's what I mean
<zid>
amd64 is already 20 years old
<karenthedorf>
If intel thinks it's so obsolete to the point they want to remove it, why should I care.
<zid>
*today* there's no reason to touch real mode, much less in 20 more years when x86s is available
<zid>
and then 20 more until it's defacto
memset has quit [Remote host closed the connection]
bradd has quit [Quit: No Ping reply in 180 seconds.]
fluix has quit [Ping timeout: 246 seconds]
brynet has quit [Ping timeout: 260 seconds]
bradd has joined #osdev
fluix has joined #osdev
Mondenkind has quit [Quit: !]
childlikempress has joined #osdev
childlikempress is now known as Mondenkind
nagitsu has quit [Server closed connection]
nagitsu has joined #osdev
hanemile has quit [Server closed connection]
hanemile has joined #osdev
LambdaComplex has joined #osdev
mcrod has quit [Server closed connection]
mcrod has joined #osdev
frkzoid has quit [Ping timeout: 248 seconds]
goliath has joined #osdev
gjn has quit [Server closed connection]
gjn has joined #osdev
vismie has quit [Server closed connection]
vismie has joined #osdev
sskras has quit [Server closed connection]
astroanax has joined #osdev
sskras has joined #osdev
rselim has quit [Server closed connection]
rselim has joined #osdev
HumanG33k has quit [Server closed connection]
HumanG33k has joined #osdev
greeb has quit [Server closed connection]
greeb has joined #osdev
nadja has quit [Server closed connection]
nadja has joined #osdev
astroanax has quit [Quit: WeeChat 4.3.4]
GeDaMo has joined #osdev
Maja has quit [Server closed connection]
Maja has joined #osdev
larsjel has quit [Server closed connection]
larsjel has joined #osdev
DragonMaus has quit [Server closed connection]
DragonMaus has joined #osdev
danlarkin has quit [Server closed connection]
danlarkin has joined #osdev
citrons has quit [Ping timeout: 256 seconds]
kkd has quit [Server closed connection]
kkd has joined #osdev
cuppajoeman has quit [Server closed connection]
cuppajoeman has joined #osdev
nohit has quit [Server closed connection]
nohit has joined #osdev
citrons has joined #osdev
<heat>
karenthedorf, fyi that was the LAPIC (or IO APIC, can't remember), not the PIC
geist has quit [Server closed connection]
geist has joined #osdev
<heat>
also the legacy PIC isn't an architectural thing, it's a platform thing
memset has quit [Remote host closed the connection]
memset has joined #osdev
Left_Turn has joined #osdev
Turn_Left has joined #osdev
Turn_Left has quit [Max SendQ exceeded]
netbsduser has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 272 seconds]
X-Scale has joined #osdev
teroshan has quit [Server closed connection]
teroshan has joined #osdev
<karenthedorf>
Yeah, legacy PIC is a PC thing, not a true x86 thing like the LAPIC. But non-PC x86 is kind of esoteric nowadays.
<karenthedorf>
Does the I/O APIC cound as a platform thing since it's part of the chipset and not the core? (Or am I wrong and it is part of the cpu proper?)
<zid>
PS4 isn't *that* esoteric :P
vdamewood has quit [Quit: Life beckons]
antranigv has joined #osdev
<nikolar>
Are there any x86 embedded boards or something
<zid>
lots, but they tend to be PCs
<nikolar>
Makes sense I guess
<nikolar>
I know there were weird 486 based devices in the 90s
<zid>
yea I should clarify I mean a PC from the software side
clever has quit [Server closed connection]
<zid>
they often eschew the hardware features of PCs, like AT/ATX/PS/2 etc
<nikolar>
Yeah I got it
<zid>
am I allowed to be a PC if I have no ps/2 port!
<karenthedorf>
What if your keyboard control isn't an external chip that's hooked back into one of the CPU's address bus lines?
<karenthedorf>
But actually not that whole franken mess.
troseman has quit [Server closed connection]
<kazinsal>
don't have to worry about how your keyboard controller works if you only accept input via RS-232 or virtual terminals attached to berkeley sockets
<kazinsal>
this shitpost brought to you by: network janitor gang
<karenthedorf>
You do if you want the A20 line to work correctly and not have your addresses wrap every MB. :D
Goodbye_Vincent has quit [Server closed connection]
Goodbye_Vincent has joined #osdev
<karenthedorf>
I should get back to trying to get the APIC(s) to work. Urgh. I enabled the LAPIC (on the boot processor), but apparently I also need to configure the I/O APIC? Also I'm supposed to disable the legacy APIC I think?
<zid>
there's a legacy apic?
<kazinsal>
apic stuff is weird
<kazinsal>
ideally you shouldn't really *need* to use the apic for interrupt routing
<karenthedorf>
There's 2, actually (or one bit of hardware that emulates two physical chips)
<zid>
you mean the PIC?
<kazinsal>
almost any PCI card made after like the mid 90s shouuuuld support MSI if not MSI-X
<zid>
It's virtualized these days, but you don't need to know that to tell it to shut up
<kazinsal>
which is a nice low-latency interrupt routing system that bypasses the IOAPICs
<karenthedorf>
Yeah, but I just want to get interrupts from the serial port.
<kazinsal>
what I do is use legacy PIC routing on core 0 for ISA stuff and run everything else on MSI/MSI-X
<zid>
APIC is the LAPIC + IOAPIC
<karenthedorf>
Which I think means I have to set up the I/O APIC.
<kazinsal>
so serial/legacy timers run on a legacy PIC emulation on core 0's LAPIC
<kazinsal>
and everything else gets shunted to assigned cores via MSI/MSI-X
<zid>
yea LAPIC is what each cpu does, IOAPIC is a per-cpu interrupt controller part, if memory serves?
<zid>
redirection table from external sources to specific LAPICs
<kazinsal>
meaning I don't ahve to deal with the nightmare circus that is PCI/IOAPIC routing
<karenthedorf>
zid: That's my understanding. There's also the legacy 8259 PIC which you just need to command to commit seppuku and then pretend it doesn't exist.
troseman has joined #osdev
<zid>
yes, the PIC, which you tell to shut up
<karenthedorf>
Yeah, I called it the "legacy APIC" earlier and that's wrong, it's not 'A'.
<zid>
correct
<zid>
there's also the x2apic and other stuff but I don't know the distinctions there
<karenthedorf>
So anyway, kill the PIC, enable the APIC by writing 0x1FF to the spurious interrupt register, and yet no serial interrupts. Sooo... that's where I'm at.
<karenthedorf>
I think x2apic is a mode for the I/O apic? and you should probabally use it, not using it is one of the things intel wants to kill off.
vdamewood has joined #osdev
<kazinsal>
I think if you want to use the IOAPIC in APIC mode to route external interrupts you need to do some wacky ACPI stuff
<karenthedorf>
Oh and then there's the fun that Pentium and P6 have buggy-ass I/O APICs which has their own bus instead of being hooked to the system bus, which means The Intel Manual spends half the chapter on interrupt controllers discussing how messed up those were instead of anything relevant in the last 20 years.
<zid>
intel manual do be like that
<zid>
there's also the XEON chapter on that too I think?
<zid>
cus the xeon did something else (the original xeon, not the cpu line, 'xeon')
<karenthedorf>
kazinsal: Urggghhh... I was hoping to not have to parse APIC for a while.
<karenthedorf>
*ACPI
<karenthedorf>
Too many acronyms starting with A
<zid>
acpi has the routing table in it, I printed mine
<zid>
it was boring
<zid>
everything was routed to core 0 as you'd expect
<kazinsal>
your DSDT might just be wrong too, because lmao, BIOS manufacturers
X-Scale has quit [Quit: Client closed]
<karenthedorf>
I'ma going to assume qemu routes everything to 0 and see if it works.
<karenthedorf>
And come back later when I have actual ACPI parsing
<kazinsal>
ACPICA is the canonical ACPI blaster but there's also `lai` by manganarm (who was in this channel once upon a time years ago I think but doesn't seem to be now) on github that is a lot smaller and can do most of the stuff you'd need
<nikolar>
Wasn't there a library you could use for acpi parsing
<zid>
yea but who wants 300kB of acpi parsers in their 2kB of osdev code :P
<zid>
DSDT, is the thing I was trying to find the name of
<nikolar>
Lel those who can't be bothered to parse acpi
<zid>
maybe not
<karenthedorf>
Doesn't it have like a whole language in it you need to interpret? Sounds wild.
<zid>
Yea, AML or something
<nikolar>
It does, yeah
<zid>
MADT!
<zid>
multiple apic description table
<nikolar>
zid see, a library doesn't sound so bad
<zid>
You don't need AML for MADT
<zid>
You need it for power management I think
<kazinsal>
you need it for IOAPIC PCI routing
<nikolar>
Yeah I forgor
<zid>
entry type 1 in the madt is the ioapic default config or something?
<zid>
for where it's mapped
<zid>
I think that's all you need
<kazinsal>
yeah
<zid>
like when you grab the pci-e base addr out of the other table
mjg has quit [Server closed connection]
<nikolar>
You need apic for ipis too, no?
<zid>
yea
<kazinsal>
ayep
<zid>
but the apic base addr is just an MSR, and your bootloader doesn't move it from the default anyway
<zid>
lapic*
dormito has quit [Server closed connection]
dormito has joined #osdev
<heat>
karenthedorf, APIC and IOAPIC are architectural
<heat>
they're in the SDM manual, not chipset docs
<heat>
(actually IOAPIC might /not/ be architectural, can't remember, but LAPIC definitely is)
<karenthedorf>
Yeah, LAPIC is for sure.
<karenthedorf>
I'm not sure on the I/O APIC
<zid>
I don't have an MADT apparently? I have an APIC table though
<zid>
and I have two i/o apics, one at fec000000 and one at cec01000
<zid>
ISA bus delivers irq0 and irq9
<karenthedorf>
Wiki says "So you can have, say, 2 I/O APICs, the first handling IRQs 0 - 23 and the second 24 - 47."
<zid>
yep, that's how mine's set up
<kazinsal>
LAPIC is "baked into" each logical core
<kazinsal>
then there's one or more IOAPICs on top of that
<zid>
MADT has the routing info, idk where you'd get that on my machine heh
<kazinsal>
relatively alright documentation on it here
<heat>
you effectively need AML for it, because then you can't get PCI interrupts
<heat>
and you need to execute \_PIC too
<kazinsal>
well, you can tell your PCI devices to keep using legacy IRQs
<karenthedorf>
My plan was *just* to get serial interrupts for now.
<kazinsal>
or tell them to use MSI
<zid>
(MCFG is the one I couldn't remember the name of, that has the pci-e base addr)
<kazinsal>
I'm weird and my awful old kernel design used an ASMP setup, though
<heat>
MSI would be great but requires all PCIe (welcome to 2024)
<heat>
and the problem is that qemu doesn't emulate MSI on many devices
<kazinsal>
MSI is in the PCI 2.1 spec iirc
<kazinsal>
so it's valid on parallel PCI
<heat>
yeah but was only made mandatory on PCIe
<zid>
maybe my hypervisor hid it from me? :P
<heat>
but really the big problem is emulators
<kazinsal>
I think every emulation of stuff like intel 825xx handles MSI if not MSI-X
<kazinsal>
even on parallel PCI on qemu/i440fx
<kazinsal>
maybe the storage processors might not? idk
<karenthedorf>
Yup, I read the wiki page on MADT, I am still nonplussed as to what I have to do.
<kazinsal>
I haven't really done a deep dive into what eg. the ubiquitously emulated buslogic SCSI controller handles
<zid>
nothing
<heat>
IDE does not, e1000 does not (IIRC), some of the GPUs do not
<zid>
as far as I know you just wake the lapic up having disabled the pic
<kazinsal>
e1000 definitely does, I've done pure MSI-X on e1000
<zid>
and the i/oapic in qemu is set up 'fine' already
<heat>
might've been e1000e?
<kazinsal>
e1000e is a higher revision thereof
<zid>
I guess you wanna revector them so you don't get them all on the same source though?
<kazinsal>
actually, my memory is bad -- e1000 handles MSI but e1000e handles MSI-X
<kazinsal>
both of which are good enough to bypass ACPI PCI vectoring bullshit
<heat>
aight
<zid>
there's info lapic in qemu, cool
<heat>
karenthedorf, port ACPICA, use it
<heat>
then thank me for the time i saved you
<kazinsal>
or port lai and write some damn documentation when you do
<kazinsal>
because the documentation for it is basically just "here's what you need to plug into it, godspeed"
<heat>
to me, lai is in the limine category
<heat>
aka not using it, too amateurish
<zid>
(and info pic, which I already knew existed, but is also useful here)
<kazinsal>
idk, lai at least seems like it has some thought put into it
<kazinsal>
it's a minimalist "get the grunchy parts of ACPI sorted" thing
<heat>
with ACPICA you at least know it'll run everywhere and work correctly
<heat>
with GRUB you know it'll... it will... uhh... boot sometimes
<kazinsal>
quite frankly nearly every single hobby osdev dork is going to go nowhere near needing things like desktop-grade ACPI plug and play whizbang firmware bug workarounds working
<heat>
i agree, but if i have a third party ACPI library i'd love for it to Just Work
<heat>
instead of Just Work Sometimes, But Not Always
<kazinsal>
so being able to get the 99% most important parts of ACPI going in a 10kb library and using post-ACPI modern stuff to do things like multicore interrupt vectoring seems like a win
<heat>
lai is 10KB?
<kazinsal>
like, I honestly don't care about the half meg of ACPI Reclaim space
<kazinsal>
I just ignore it because I don't target anything with less than a gig
<kazinsal>
ACPI can hold onto that forever
<karenthedorf>
So this is what I currently do https://pastebin.com/m7t35e36 (and then `sti`) But... no interrupts get through except one from an `int $255` instruction I run (pretty sure I enabled them over on the serial config side)
<karenthedorf>
The Higher-Half Direct Map limine gave me. So all physical memory should be mapped there.
<heat>
that sounds impossible
<kazinsal>
I really need to figure out limine one of these days, if only to figure out how it works
<zid>
clear disable bit, set up lint0 and lint1, set up spurious, set task prio, destination format
<zid>
are the full steps
<zid>
idk what the *minimum* steps are
<heat>
it's mapping *all* of physical memory? are you sure it's not just the -2GB bit?
<karenthedorf>
This is x64, we have way more than 2GB :D
<zid>
we're itanium!?
<kazinsal>
one day there'll be a multiboot 3 that supports x64 out of the box
<zid>
fuck, I have no idea how the itanium ioapic works
<kazinsal>
also one day the bombs will fall and we'll all be free of this shit
Goodbye_Vincent has quit [Quit: Ping timeout (120 seconds)]
<heat>
i like when my questions go above people's heads because they use limine to skip important steps
<heat>
in any case, that's not how you configure the APIC
<zid>
I think configuring the spurious boy might be hard required
<kazinsal>
honestly the only reason I still support grub is because I like being able to blat a new bootimage to build:/araxes/tftp/ and then type `system reboot now` into the shell
<zid>
looks like every single pin is set to irq0 on cpu0 to me?
<heat>
as i said, that's not how you use the APIC
<zid>
and all are masked
<karenthedorf>
So yeah, looks like everything is masked at the I/O apic level
<heat>
it's all masked and uninitialized
<karenthedorf>
heat: Yes, I am aware, I'm trying to work out what I need to do to not have it all masked and broken.
<zid>
so you need to write a value above 0x10 to the ioapic then write some bits for where to send it and how
<heat>
i linked you my code
<heat>
see ioapic_init
<zid>
afaik it's like the ppu on the nes where it has an address reg and a data reg?
<zid>
so you write the address 0x10 to set vector table 0 entry into the address reg, then write.. some vector / level / etc info to the data reg
<karenthedorf>
Yeah, I don't know where those regs live yet, so I should get to parsing the MADT. After I've read heat's code
<zid>
madt or apic apparently, but mine's at FEC if you just wanna try it :P
<kazinsal>
I'm at the point where I'm right about to just rewrite everything from scratch myself because, why not
<zid>
idk if anybody bothers to move it, or if you even can move it, like the LAPIC
<kazinsal>
good opportunity to make all the important parts platform agnostic
<heat>
ioapic_init, apic_timer_smp_init, ioapic_unmask_pin are the key functions there
<heat>
oooh kazinsal are you doing a UNIX
<zid>
fec is in the acpi spec as the 'example' address
<kazinsal>
the unix is my side side project
<heat>
you're dropping pdp assembly for CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
<kazinsal>
the unix runs on an 8088
<kazinsal>
the main side project is a proper modern-ish 64-bit network core OS
<kazinsal>
routing, switching, firewalling, etc
<kazinsal>
the unix is for when I get bored and want to hack on bad hardware
<heat>
yah
<heat>
i've kinda wanted to add routing to my OS but i honestly don't know where to start, and i have little hands-on experience on the matter
<zid>
dev: ioapic, id ""
<zid>
version = 32 (0x20)
<zid>
mmio 00000000fec00000/0000000000001000
<zid>
gpio-in "" 24
<zid>
in `info qtree` in my qemu, so yea, it's there
<kazinsal>
I figure the unix from scratch on a 45 year old platform will give me an advantage when the nukes pop and someone needs to reimplement the internet using late 1960s technology
<zid>
tbh you could probably get away with never checking the madt or apic tables, the chances of any machine anyone ever runs your code on not having it precisely there seems unlikely :P
mjg has joined #osdev
GreaseMonkey has quit [Server closed connection]
xenos1984 has quit [Read error: Connection reset by peer]
<karenthedorf>
So the IOAPIC has two memory mapped registers (address and data), both 1 byte wide, but 16 bytes apart? I know that's perfectly possible just... weird. Probabally some hardware wiring choice we're all stuck with.
<zid>
4 bytes wide, 16 bytes apart
<karenthedorf>
Right, I can't into maths. Urgh, I should probabally sleep
<zid>
and each routing table entry is 8 bytes so takes two addresses
<zid>
10 and 11, 12 and 13, etc
<zid>
the high bits seem to be for routing to different cpus, low bits are for edge/level/high/low/vector
sham1 has quit [Server closed connection]
dzwdz has quit [Server closed connection]
sham1 has joined #osdev
dzwdz has joined #osdev
Left_Turn has joined #osdev
bauen1 has quit [Ping timeout: 248 seconds]
tanto has quit [Quit: Adios]
vancz has quit []
pie_ has quit []
tanto has joined #osdev
vancz has joined #osdev
pie_ has joined #osdev
Turn_Left has quit [Ping timeout: 265 seconds]
Arsen has quit [Server closed connection]
Arsen has joined #osdev
<karenthedorf>
Thanks for the help btw, even if I'm being a bit dense and a bit more sleep-deprived.
<zid>
I'm just looking it up myself, for my own edification
<zid>
then sperging my superior knowledge all over you
<zid>
it strokes my napoleon complex
<kazinsal>
yeah this is one of those things I kinda did a "set and forget" on ages ago and never really remembered all the details of myself
xenos1984 has joined #osdev
<karenthedorf>
I am now returning to the font of all knowledge, the intel manual, but with more knowledge I should hopefully understand it better on the second time through.
sbalmos has quit [Server closed connection]
<heat>
i wrote my code 8 years ago
sbalmos has joined #osdev
<heat>
the IOAPIC+LAPIC thing is... funky
<karenthedorf>
It does make sense to have an interrupt controller for the CPU, then another for each core. It just doesn't make the lives of OS devs easy :D
ramenu has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<zid>
ioapic is just a memory mapped PIC with more bits for routing, doesn't seem bad at all
<zid>
I'd never looked *super* deeply at it
<zid>
lapic is kinda scary but the default config seems usable
vdamewood has quit [Quit: Life beckons]
<heat>
the interrupt controller is in theory not on the CPU, but on the platform itself
nikolar has quit [Server closed connection]
pitust has quit [Server closed connection]
pitust has joined #osdev
gmodena has quit [Server closed connection]
gmodena has joined #osdev
<karenthedorf>
Hmm, my LAPIC is at FEE0`0900 not FEE0`0000? Odd?
<karenthedorf>
I guess limine or qemu could be responsible... I probabally shouldn't care though.
<karenthedorf>
Oh, there's flags in the APIC_BASE_MSR as well as the address... ugh
memset has quit [Remote host closed the connection]
memset has joined #osdev
lanodan has quit [Server closed connection]
lanodan has joined #osdev
memset has quit [Remote host closed the connection]
memset has joined #osdev
thinkpol has quit [Remote host closed the connection]
thinkpol has joined #osdev
Starfoxxes has joined #osdev
obrien has joined #osdev
astroanax has joined #osdev
<astroanax>
ll
<astroanax>
any good resources on low level vmem management?
<Ermine>
heat: back to linear algebra, the really hard thing there is tensor theory
<mjg>
:D
<mjg>
lemme tell you how i failed to pick up a chick once
<mjg>
at my first job we had a bunch of women around my age in customer service
<mjg>
i was studying some algebra on my lunch break
<mjg>
she was sitting nearby and we started chatting
<mjg>
i thought i sound smart 'n shit
<mjg>
turns out he was one year older and studying physics
<mjg>
and the shit i was studying was ez stuff she already did
<Ermine>
learning algebra isn't how you flirt with women
karenw has joined #osdev
<mjg>
dude
<Ermine>
unless you're on the math faculty
<mjg>
i picked up a chick on unix, no joke
karenthedorf has quit [Ping timeout: 244 seconds]
<mjg>
she was in the CS program though
<mjg>
so you know, don't talk to me about women!
<Ermine>
I was advised to prefer humanitarian faculties
<mjg>
i don't want to sound like andrew tate, so i'm gonna leave it like that
<Ermine>
til
<Ermine>
Also yeah, when you get to advanced stuff, everything you've learned in the past course feels ezpz
<mjg>
c'est la vie innit
<mjg>
i remembered having tons of funs writing programs i could not be fucked to write today
karenw is now known as karenthedorf
astroanax has quit [Quit: WeeChat 3.8]
ghostbuster has quit [Ping timeout: 252 seconds]
ghostbuster has joined #osdev
<Ermine>
Meanwhile, seems like I need to take a step back and learn opengl first
<mjg>
opengl?
<mjg>
that's still a thing?
<Ermine>
yes, and it will be a thing
bauen1 has joined #osdev
Turn_Left has joined #osdev
asymptotically has quit [Server closed connection]
asymptotically has joined #osdev
Left_Turn has quit [Ping timeout: 252 seconds]
brynet has joined #osdev
meisaka has quit [Ping timeout: 256 seconds]
memset has quit [Remote host closed the connection]
memset has joined #osdev
edr has joined #osdev
<vin>
Is there a way to trigger memory swapping for a particular process? That is only identify cold pages for a process and swap it out. I don't think linux supports per process. I did try per cgroup by setting memory limit but it doesn't seem to work
Gooberpatrol66 has quit [Ping timeout: 248 seconds]
hussein has quit [Server closed connection]
shan has quit [Server closed connection]
shan has joined #osdev
khimaros has quit [Server closed connection]
khimaros has joined #osdev
<heat>
mjg, mof do you ever run out of funny stories
<heat>
real q here
<mjg>
bro
<mjg>
i have been alive for significantly longer than you
<mjg>
liek talk t osomeone pushing 40
<heat>
an oldie? i would never!
<heat>
meanwhile the guy asked about "low level vmem management" and no one replied :(
<kof673>
> I figure the unix from scratch on a 45 year old platform will give me an advantage when the nukes pop yes, i believe john titor warned about a similar scenario, unix would have to be restored
josuedhg has joined #osdev
TkTech has quit [Ping timeout: 252 seconds]
qubasa has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
brynet has quit [Quit: leaving]
brynet has joined #osdev
* geist
yawns
<geist>
howdy folks
<gog>
hi
joe9 has joined #osdev
joe9 has quit [Client Quit]
sortie has quit [Remote host closed the connection]
sortie has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
Terlisimo has quit [Remote host closed the connection]
<Ermine>
hi geist
<geist>
hola!
pkal has joined #osdev
particleflux_ is now known as particleflux
<gog>
hi
Starfoxxes has quit [Remote host closed the connection]
Gooberpatrol66 has joined #osdev
* Ermine
gives gog a piece of cheese
* gog
is fasincated
GreaseMonkey has joined #osdev
josuedhg has quit [Quit: Client closed]
heat has quit [Remote host closed the connection]
linear_cannon has quit [Ping timeout: 246 seconds]