SnowOS

[hushed spire]

AH HAH!

I can get input from serial >:3

[marsh pecan]

This is a bit of a rabbit hole ?

[narrow storm]

You could also use a ticket lock which ensures fairness etc

And is pretty simple to make

[hushed spire]

started working on a minimal debugging shell

[hushed spire]

Oh yeah I need to figure out how to remap the kernel

[narrow storm]

i just parse my own elf

and then use the bootloade to tell me where i was loaded

[hushed spire]

Okay, was guessing I might have to do something like that

ah, that means I'll need stuff to read a PE

idk what namespace that would be under, I guess a ldr namespace

[narrow storm]

You can also add linker symbols

Arround every section that needs special perms

Then read the addresses of those etc

But that’s less cool imo

Though it is common

You also don’t need full elf/pe loading

Just parsing of the sections and address ranges and there perms

[hushed spire]

I mean I have to write PE header parsing anyhow so might as well do it this way

[hushed spire]

ye I know :3

[narrow storm]

Exactly

Also you can probably make it in userspace first

Then port it

(Or be cool and make it a single header portable library)

[hushed spire]

I've made a PE parser before already, so shouldn't be too hard

[hushed spire]

bloody hell 😭

I forgot to zero out a page

[hushed spire]

welp, I'm getting a GPF 🥀

I'll figure it out tmrw

[hushed spire]

Scheduling today maybe 👀

If I can figure out why I'm getting a GPF

[hushed spire]

actually no probably not today

I still have to work on slab

maybe tmrw or the day after tho :3

[hushed spire]

was busy yesterday :p

anyhow

yeah lemme try and solve this

[hushed spire]

limine_file *yukiImage = hal::retrieveYukiImage();

ke::print("Physical Address of Yuki 0x%llX\r\n", reinterpret_cast<uintptr_t>(yukiImage->address) - hal::retrieveHhdmOffset());

💀

[fresh knoll]

man this os looks good

im building it rn

[hushed spire]

pretty sure I need executable address here not executable file:p

[hushed spire]

thx! Even if I'm not that far along lol

[fresh knoll]

yeah still but making an OS is hard

i had my pain with mlibc

[hushed spire]

speaking of which, I need to look at mlibc's source and see if it's worth trying to port or not

[fresh knoll]

i mean you just have to config

and compile

and it will generate a libc

[hushed spire]

the issue is I'm not POSIX* (natively) so I get the feeling it isn't that simple

[fresh knoll]

but you will need syscalls for that

[hushed spire]

This was such I stupid mistake I dunno how I missed that 🥀

anyhow it's fixed now :3

[fresh knoll]

[binaries]
c = 'clang'
cpp = 'clang++'
c_ld = 'lld'
cpp_ld = 'lld'
strip = 'true'

[built-in options]
c_args = ['-target', 'x86_64-unknown-windows', '-ffreestanding', '-mno-red-zone', '-mno-mmx', '-mno-sse']
cpp_args = c_args
cpp_link_args = ['-target', 'x86_64-unknown-windows']

[host_machine]
system = 'uefi'
cpu_family = 'x86_64'
cpu = 'x86_64'
endian = 'little'
there is no nasm decleration on the pushed repo

[hushed spire]

oh :p

my bad lol

[fresh knoll]

The Meson build system
Version: 1.3.2
Source dir: /home/constantine/SnowOS
Build dir: /home/constantine/SnowOS/build
Build type: cross build
Project name: SnowOS
Project version: 0.1.0

meson.build:1:0: ERROR: 'nasm' compiler binary not defined in cross or native file

A full log can be found at /home/iaintleakingmyuserbro/SnowOS/build/meson-logs/meson-log.txt

[hushed spire]

okay, I presume all you have to do is add nasm = 'nasm' under [binaries]

[fresh knoll]

yeah i willl lol and test it out

[fresh knoll]

The Meson build system
Version: 1.3.2
Source dir: /home/myusernamestartswithc/SnowOS
Build dir: /home/myusernamestartswithc/SnowOS/build
Build type: cross build
Project name: SnowOS
Project version: 0.1.0
Nasm compiler for the host machine: nasm (nasm 2.16.01)
Nasm linker for the host machine: clang ld.lld 18.1.3

meson.build:1:0: ERROR: Unknown C std ['gnu23']. Possible values are ['none', 'c89', 'c9x', 'c90', 'c99', 'c1x', 'c11', 'c17', 'c18', 'c2x', 'gnu89', 'gnu9x', 'gnu90', 'gnu99', 'gnu1x', 'gnu11', 'gnu17', 'gnu18', 'gnu2x', 'iso9899:1990', 'iso9899:199409', 'iso9899:1999', 'iso9899:2011', 'iso9899:2017', 'iso9899:2018'].

A full log can be found at /home/myusernamestartswithc/SnowOS/build/meson-logs/meson-log.txt
it was not that only 😭

[hushed spire]

what's your clang version?

[fresh knoll]

18.1.3

[hushed spire]

ah

[fresh knoll]

sudo apt installed 18.1.3

[hushed spire]

ye you might wanna update clang, tho you may also be able to change it to gnu17 since I technically use little to no C in the OS

ah wait, does 18.1.3 support c++23/26? 😭

[fresh knoll]

nuhuh@mintpc:~$ clang++ -std=23
clang++: error: no input files
nuhuh@mintpc:~$ clang++ -std=26
clang++: error: no input files

[hushed spire]

okay I think that version should support c++23 but not c++26

[hushed spire]

anyhow, back to working on slab :3

I also think I will implement object caching

for properness

I should implement a doubly linked list in userspace first tho

no

sorry

I meant a circularly linked list lol

[hushed spire]

allocation works (with small slabs), now I have to do freeing

[hushed spire]

uhh, I'm guessing I need a tail pointer

otherwise I don't think I have anyway of finding the end of the list

admittedly I don't really know why it has to be a circular linked list

[hushed spire]

oh wait, no I don't :p

[lunar vortex]

who says it has to?

if you were looking at my kernel I use circular linked lists because they're branchless

[hushed spire]

Bonwick apparently

[lunar vortex]

where

[hushed spire]

of all its slabs.``` Under 3.3 Freelist Management

[lunar vortex]

ah

idk

[hushed spire]

despite that, yeah I don't think it has to be a circular list

[marsh pecan]

It's an implementation detail

Circular lists are basically normal linked lists, with the exception that the nodes are connected to the head instead of nullptr at the end, which makes it a little bit faster

(since you don't have to do nullptr checks and stuff like that)

We're you doing your kernel in C++?

[hushed spire]

yeah

[marsh pecan]

I have this https://gitlab.com/mishakov/pmos/-/blob/main/libs/sysroot/include/pmos/containers/intrusive_list.hh?ref_type=heads

[hushed spire]

aight, back to working on slab >:3

[serene lake]

https://tenor.com/view/courage-the-cowardly-dog-gif-25234702

[hushed spire]

this is acceptable right?

typedef struct _SLAB {

    typedef struct _BUFCTL_SMALL {
        _BUFCTL_SMALL *next;
    } BUFCTL_SMALL;

    // External Bufctl
    typedef struct _BUFCTL {
        _SLAB * slab; // Pointer to the slab of which this bufctl belongs to
        _BUFCTL *next;
    } BUFCTL;

    _SLAB *prev;
    size_t objectSize;
    uint64_t refCount;

    union {
        _BUFCTL_SMALL *bufctlSmall;
        _BUFCTL *bufctl;
    };

    _SLAB *next;
} SLAB;

I suppose I could also use a void * and just reinterpret_cast instead of using a union, but I don't feel like it :p

uh

actually I dunno if an external bufctl needs a pointer to it's slab

I just remember seeing that somewhere

[lunar vortex]

it does, but you can do clever tricks to avoid it

[hushed spire]

oh? 👀

[lunar vortex]

for one you could restrict the slab size to one page and always embed the slab data inline (which might prove less wasteful for certain sizes) and/or you can store a pointer in the struct pages associated with slab memory

[hushed spire]

Well yeah, obviously I can embed the slab data for certain sizes, but it seems like I'm not really supposed to do that above a certain point, at least that's what I would be led to believe according to the paper. Granted, I could just... not, support large slabs, but I don't know how reasonable that is :p

I mean I can't believe it's super common that you allocate something bigger than 512 bytes, so I don't think having large slabs is critical, but still

[lunar vortex]

that's what the paper says

freebsd for example had support for only page size slabs for a very long time, in fact they might still do

[hushed spire]

aight, good to know

[hushed spire]

Okie imma finish the code up some and commit my ultra shrimple Slab allocator to the git

[hushed spire]

okay I think the slab works now?

or at least

the list is behaving how I would expect it to

although I don't really know what this is about

[hushed spire]

uhhh, how the heck do I use the module request

oh

I typed module: instead of module_path: 🥀

[hushed spire]

I guess I should fix my valloc implementation because uACPI doesn't work

[narrow storm]

It’s in the same format as specifying the executable

[hushed spire]

Man I see some of the things other kernels here can run and I'm like "Wow! It would be really cool if I could do that stuff!"

but then at the same time

I really don't wanna write a UNIX-like :p

[narrow storm]

x11 runs on windows

[hushed spire]

wait it does

[narrow storm]

well it can

you very well could port it you make your own X server implementation

and still have some cool ports

[hushed spire]

I did kind of wanna do the Window Manager myself though

[hushed spire]

okie I think imma work on vmem a lil bit

won't do much, probably will just add some checks for whether the slab is initialized

also I know LoC doesn't mean much but I still feel like my kernel is notable small

yet somehow it's almost 100KiB 💀

removing /debug makes it slightly better ~75KiB

[hushed spire]

heads up for anyone following this thread, I'll probably be taking a break for a little bit

I mean I still wanna try and launch a userspace process before the end of the month

but after that

gonna take a break and work on some other projects

[hushed spire]

alright, hopefully this should only take like a day or two

still no timer

oh well

who needs a timer anyways

[narrow storm]

You need one for preemption, or well you need some interrupt source

Otherwise one app could trap you inside it

But an interrupt isn’t the only way to switch tasks

[hushed spire]

who, needs preemption, purely cooperative scheduling is where it's at

[narrow storm]

😭

A timer isn’t too hard

Just find any timer with a known frequency

Then calibrate the LAPIC

Your done

[hushed spire]

out of curiosity, what other way would you switch tasks?

[narrow storm]

Cooperative lol

Like when a task wants to sleep

[hushed spire]

oh

right

syscall doesn't count as an interrupt does it 😛

[narrow storm]

An interrupt just runs the task switch function like any other task wanting to sleep etc

Nope because it’s controlled by the user

And it could never call it

But a syscall could then run task switch inside the kernel and switch tasks

[wanton path]

Interesting

[narrow storm]

When you do a syscall you switch to the threads kernel stack (to not use the user one) and your back running on that kernel threads context

The task just jumps to user code and drops privileges until it runs syscall or gets an interrupt etc

[narrow storm]

Hm?

[hushed spire]

I know but I have yet to figure out why uACPI isn't cooperating 🥀

[narrow storm]

Parse the tables yourself

Figure it out later when you need AML

[hushed spire]

uh, right, how would I go about doing that?

[narrow storm]

You can look at my old kernel repo or like read the wiki

It has some decent pages on the format of the tables

[hushed spire]

can access the RSDP!

[hushed spire]

also I didn't know the ACPI tables were mapped in the HHDM?

[narrow storm]

Btw I wouldn’t use the address the tables give you for the local APIC

Just read the MSR for where it is

(IOAPIC is separate tho)

[marsh pecan]

ACPI is authoritative

[narrow storm]

I’d consider the MSR to be more so considering it’s the current status of the CPU

[marsh pecan]

Iirc you have to set MSR to what ACPI tells you

Linux does it

[narrow storm]

Huh interesting

[void elm]

U dont lol

[void elm]

It is since it literally reflects the current state

[marsh pecan]

Yeah, I do it in my kernel

You can probably also check limine or something

https://gitlab.com/mishakov/pmos/-/blob/main/kernel/arch/x86/interrupts/apic.cc?ref_type=heads#L82

I need to fix my SMP memes though

[marsh pecan]

https://elixir.bootlin.com/linux/v7.0.1/source/arch/x86/kernel/acpi/boot.c#L143 ?

[void elm]

I explained it before

[marsh pecan]

yeah, but there were too many messages in your thread since then

[void elm]

It's random bs that happens to work

it was never changed because it never broke

but it wasnt done because acpi is somehow more authoritive than the literal cpu msr

[marsh pecan]

yeah

[marsh pecan]

wait

[hushed spire]

uhm, I wanna say that looks right

it's not greater than 0x05F5E100 so

[marsh pecan]

it looks right for qemu

also, it is?

[hushed spire]

??

I think 0x989680 is less than 0x05F5E100 :p

[void elm]

u have 2 cases:

1. lapic disabled (in that case cpuid is cleared)
2. lapic enabled and has a valid base

for case 2, if that has a different base set u really dont want to change it because it's probably relocated for a good reason. What you should do is record it and apply it for all APs as well

[marsh pecan]

Idr

[void elm]

also didnt we see in code that it rewrites the address it gets with what's currently set by bios?

[marsh pecan]

can you find that conversation?

[narrow storm]

What do you do when the LAPIC is disabled?

[void elm]

you won't see it supported in cpuid so u just assume it doesnt exist

it's usually disabled for a good reason

[void elm]

too lazy but whatever, u can just do what linux does

[narrow storm]

Huh, i guess I would need some fallbacks in that case on x86-64? I thought it was architectural

So I will need to support PIC

[void elm]

i just panic if it's not enabled

[hushed spire]

that's what I was gonna do

[void elm]

it is technically, but nothing prevents me from doing wrmsr(apic_base, 0)

which clears cpuid

[narrow storm]

Huh neat

I could force re enable it via a cmdline on fuckass hardware ig

And then panic with a message saying that

[void elm]

i mean yeah thats what linux has

[narrow storm]

So Linux panics too?

Good enough for me then

[void elm]

no..

[narrow storm]

Ah

[void elm]

it has a command line to force enable it

[narrow storm]

Ahhh sorry

I could just support PIC but that makes things wayyy more painful, though it may be fine if I only allow legacy hardware though it and special case it

[void elm]

i mean its not exactly hard, just means all interrupts will be delivered to cpu 0

and msis are unusable

[narrow storm]

and no SMP because you can’t IPI right?

[void elm]

yes

[narrow storm]

Yeah so not too bad to special case for PS/2 & serial then disable things needed MSI/X etc

Ty

[void elm]

yeah i just dont see any reason to support it frankly, since its not a realistic configuration

like all x86-64 hardware that has ever existed had lapics

so its a meme/vm config

[narrow storm]

I think they all pretty much have IOAPICs too? I don’t think any chipset when x86-64 was made even lacks it other than meme/vm stuff

[void elm]

i guess, but ioapic is not really a hard dependency, if you have no legacy interrupts you have no need for ioapics

[hushed spire]

I don't have to do much configuration of the HPET if I'm just using it to calibrate the LAPIC right?

[void elm]

exactly 0 other than enabling it

[hushed spire]

coolio :3

[void elm]

basically id support pic-only mode if u wanna support 32-bit cpus

[marsh pecan]

pic is pita to detect though

I support ACPI PM timer though

[void elm]

no need to detect it if u have no lapic

u just know it exists then

[marsh pecan]

Oh, I confused PIT and PIC again...

yeah

though PIC only is like 386/486 machines or broken firmware?

So I didn't bother supporting them myself

[void elm]

yeah i wont bother either

[marsh pecan]

Anything pre-pentium is the insanity territory in my eyes

[hushed spire]

This should work right?

void hal::x64::hpetSleep(uint64_t ms) {
    const uint64_t ticks = (ms * hpetFrequency) / 1'000;
    uint64_t startCount = readHpetRegister(HPET_MAIN_COUNTER_VALUE);

    while (readHpetRegister(HPET_MAIN_COUNTER_VALUE) < startCount + ticks);
}

I should have a generic mmioRead/Write, but ignore that :p

[narrow storm]

Counter can rollover can’t it?

Iirc HPET can be 32bit?

[hushed spire]

it's can?

[void elm]

yeah u need to use a subtraction there

[hushed spire]

ah

[narrow storm]

Yes

I think it’s common on AMD?

[void elm]

amd hpet is always 32-bit yes

[hushed spire]

dang, didn't know that =/

[void elm]

but if u do (current_ticks - base_ticks) < needed_ticks it will always work fine

[hushed spire]

ah, okay that makes sense

Well, if I can say anything about this, it at least feels better than my first attempt :p

anyhow, LAPIC time

oh ye

I also need a TSS

I'll do that after tha LAPIC :3

[hushed spire]

I'm being scammed

[narrow storm]

do you also OR in the timer mode?

that is also offset 0x320 right

also i wouldnt read in on that register

[hushed spire]

ye

[narrow storm]

just write to it with the mode you want

[hushed spire]

oh

okie

[narrow storm]

i do mmio_write_offset_32(apic_address, APIC_REGISTER_TIMER, 0x20 | APIC_MODE_TSC_DEADLINE); (if its supported ofc)

[hushed spire]

is it just me or does that seem kind of low?

[narrow storm]

Probably

Though I’d check in real hardware

Maybe it’s a VM thing

[hushed spire]

Imma blame hpetSleep, I think it's broken 🥀

I say sleep for 1 second and it doesn't sleep for 1 second

[lunar vortex]

show code

[hushed spire]

https://github.com/UtsumiFuyuki/SnowOS/blob/main/yuki/source/hal/amd64/timers/hpet.cpp

[lunar vortex]

the counter clock period should be u64

not u32

[hushed spire]

oh shoot right

[lunar vortex]

try that

no nvm

i am a liar

it is 32 bits

[hushed spire]

oh

was boutta ask why it needed to be 64bit lol

[lunar vortex]

well you didnt reset the counter

thats something

idk if thats the problem

https://github.com/rdmsr/zag/blob/master/src/platform/acpi/hpet.zig#L19-L40

this is what I do

[narrow storm]

https://git.evalyngoemer.com/evalynOS/evalynOS-old/src/branch/dev/kernel/src/drivers/x86_64/timers/hept.c
this is what I do aswell

Also make sure to use inline assembly for MMIO functions
And to always a normal “mov” and have a constraint to always use “r/eax”

[lunar vortex]

that looks the same as what he's doing

[narrow storm]

I have no idea then

Last time I checked my HPET code worked

[lunar vortex]

idk i think volatile is ifne

[narrow storm]

It could still generate other instructions not suitable for MMIO

And AMDs manuals say not using EAX is improper for some cases

I mean I use volatile

But like do as I say not as I do

Do as the manual says

And I don’t wana have to find that manual

But you can search previous convos on the discord

[void elm]

That was talking about ECAM

[lunar vortex]

on x86 at least volatile should be fine?

[void elm]

No

It doesn't guarantee any sort of specific instruction that will be used

[narrow storm]

Fair but it can’t hurt to use eax since it’s also the return register and works our mostly

[void elm]

Only inline ASM is a guarantee

[void elm]

Yes

[lunar vortex]

yes I know

but does that matter

[void elm]

Well it will crash kvm

[lunar vortex]

for what?

the ecam stuff?

[void elm]

Because it can only emulate a small subset for mmio

[void elm]

Any mmio

Because mmio works via pagefaults and emulation

[hushed spire]

soo, how do I deal with 64bit read/write, do I just have a high and low var and stitch them together or something?

[narrow storm]

You use rax

[lunar vortex]

no because that is not atomic

so you use rax

[hushed spire]

oh

okay

[narrow storm]

And for 16bit you use ax or whatever

[marsh pecan]

I do this https://gitlab.com/mishakov/pmos/-/blob/main/kernel/arch/x86/time/hpet.cc?ref_type=heads#L194

[marsh pecan]

Also, I think the manual says that even if you read it as u64, the hardware can do 2 32 bit reads, so the counter can be inconsistent?

[narrow storm]

You could mask the upper 32bits and pretend it’s always a 32bit timer and handle rollover

[marsh pecan]

[narrow storm]

That’s spesific to HPET

[marsh pecan]

What was rax about then?

[narrow storm]

For 64bit MMIO registers

You should still read the full register if it’s a 64bit register

[marsh pecan]

You read high 32 bits, the low 32 bits, then high 32 bits again

if high 32 bits change, you try again

[hushed spire]

so, something like this?

static inline void mmioWrite64(uint64_t address, uint64_t reg, uint64_t value) {
    __asm__ volatile ("mov %%rax, (%%rbx)" :: "b"(address + reg), "a"(value));
}

static inline uint64_t mmioRead64(uint64_t address, uint64_t reg) {
    uint64_t ret{};
    __asm__ volatile ("mov (%%rbx), %%rax" : "=a"(ret) : "b"(address + reg));
    return ret;
}

[narrow storm]

You have to use compiler constraints to make it work

[marsh pecan]

yes, except that rbx is not the best choice

[hushed spire]

oh :p

[narrow storm]

You should let the compiler pick for RBX

[hushed spire]

uhh, how would I do that?

[narrow storm]

https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html

https://gcc.gnu.org/onlinedocs/gcc/Constraints.html

[marsh pecan]

I mean I do this https://gitlab.com/mishakov/pmos/-/blob/main/libs/sysroot/include/pmos/io.h#L20
(and I haven't needed to do 64 bit mmio accesses on x86)

(if you want 64 bit accesses, you just replace movl with movq)

[lunar vortex]

why not just enforce *ax everywhere

instead of a bespoke pci_mmio_read

[marsh pecan]

idk, it lets the compiler do more optimizations I guess

[narrow storm]

*ax isn’t even bad for general MMIO and it won’t really hurt the compiler given it’s the return register for reads and an extra mov and xor for writes if it dosnt inline and optimize it

Modern compilers will do just fine

[marsh pecan]

it didn't feel good to me

you have all of these registers, why restrict yourself for eax for no reason

if a hypervisor has a skill issue with everything else, it's on them

[hushed spire]

thiiiiiiis mayhaaaps?

static inline void mmioWrite64(uint64_t address, uint64_t reg, uint64_t value) {
    __asm__ volatile ("mov %%rax, (%0)" :: "r"(address + reg), "a"(value));
}

static inline uint64_t mmioRead64(uint64_t address, uint64_t reg) {
    uint64_t ret{};
    __asm__ volatile ("mov (%1), %%rax" : "=a"(ret) : "r"(address + reg));
    return ret;
}

[marsh pecan]

inline uint64_t mmioRead64(uint64_t *ptr)
{
    uint64_t data;
    asm volatile ("movq %1, %k0" : "=a"(data) : "o"(*ptr) : "memory");
    return data;
}
inline void mmioWrite64(uint64_t *ptr, uint64_t data)
{
    asm volatile("movq %k0, %1" :: "a"(data), "o"(*ptr) : "memory");
}

Also, why are you using uint64_t for pointers

Just no

It becomes a mess, trust me

instead of passing a register, you can just pass address + reg as pointer

[hushed spire]

true

[marsh pecan]

Iirc this should also do the x86 vector access thing

like this can compile to something like movq %rax, 20(%rdx, %ecx, 8)

[hushed spire]

hpetSleep works now!

[remote junco]

Looks cool

[narrow storm]

what twas the issue

[remote junco]

Btw if u wanna garuntee inline, you can do so with __attribute__ on gcc

Jst sayin

[hushed spire]

I'm guessing my mmio functions

[narrow storm]

the compiler should be allowed to do its own optimization

if its static inline for somthing small like that it will anyways

[remote junco]

im saying if for any reason you need it

[marsh pecan]

Nah, it's inline so that there are no duplicate symbols

like inline doesn't actually mean inline in C/C++ since forever?

(I mean idk about C, but it's in C++ for sure)

[remote junco]

Inline means inline

Ik abt the way it works for linking tho dw

[marsh pecan]

https://en.cppreference.com/cpp/language/inline

[narrow storm]

thats static??

[marsh pecan]

No

[narrow storm]

since C++ 17

[marsh pecan]

Yes, since 10 years ago

[narrow storm]

An inline function or variable(since C++17) with external linkage (e.g. not declared static)

[marsh pecan]

Because the meaning of the keyword inline for functions came to mean "multiple definitions are permitted" rather than "inlining is preferred" since C++98, that meaning was extended to variables.

Idk what the standard says, but it's clearly "don't complain about multiple definitions" to me

[marsh pecan]

and static means local to the file

[narrow storm]

it disables external linkage of it

or makes it persist across function calls for local vars

[marsh pecan]

yeah

[hushed spire]

lol, interrupts were disabled and I wasn't getting anything :p

works now!

I dunno if I want to insure interrupts are enabled, but for testing purposes, I have

now I need to add support for x2APIC

and just generally clean up the code some

but for now I work on scheduler

[narrow storm]

Btw it’s the same thing

Just MSRs instead of MMIO

[hushed spire]

I'll probably also work on enabling the IOAPIC and IRQLs when I get back from break :3

[narrow storm]

And diffrent offsets

And one register is different and needs a special case

(For the better)

[marsh pecan]

you need iommu for that

[void elm]

Why would u need iommu for it

[marsh pecan]

so that you can use lapic IDs > 256

Idk, both Intel and AMD went "all operating systems support iommu anyway, so we won't bother with new msi format"

[void elm]

"use" for MSIs

u can still use them just fine

just dont map interrupts to them

[marsh pecan]

but you still can't just replace xapic code with x2apic, and not run into issues

[marsh pecan]

you've got to handle this in interrupt allocation code

[void elm]

u can, u just have to have an if statement in irq_allocate or wahtever

[hushed spire]

alright so yesterday I got a simple PE loader working

Today I'll be working on syscalls and then hopefully actually executing the PE in usermode

[hushed spire]

it doesn't actually do anything yet tho

it does swapgs, shows what syscall was invoked, and then immediately halts

[narrow storm]

Add a syscall for printing a string (and for a challenge make it safe )

And then make one for exiting

So you can make a hello world for your kernel

[hushed spire]

yup, that's what I was going to do 👍

[narrow storm]

Btw you may need a special reaper thread

Where it’s entire job is to gather threads that exited

And to reclaim all the memory

[hushed spire]

ah ye, okay :3

[narrow storm]

Basically it would be pretty bad™ if you freed your own stack while your using it lol

[hushed spire]

true

oh, that actually just... worked... was kind of expecting it to break tbh anyhow lemme make it switch to the kernel stack

[narrow storm]

Me when your running kernel code with a userspace controlled stack

🥀

Oh wait

[visual walrus]

XD

[narrow storm]

I can’t read

😭

I’m so sorry

[hushed spire]

you're fine lol

[visual walrus]

struct SyscallRegs {
u64 rax = {};
u64 rbx = {};
u64 rcx = {};
u64 rdx = {};
u64 rsi = {};
u64 rdi = {};
u64 r8 = {};
u64 r9 = {};
u64 r10 = {};
u64 r11 = {};
u64 r12 = {};
u64 r13 = {};
u64 r14 = {};
u64 r15 = {};
};

the struct for it btw

if you want

[narrow storm]

I think they can make it themselves lol

[lunar vortex]

i hate when you do this

diamondmaster

[narrow storm]

Also the = {} stuff is redundant

[visual walrus]

srry

[lunar vortex]

youre always just sending random snippets of code

[narrow storm]

Like if you’re gonna share structures, atleast make sure it’s somewhat not completely trivial?

[lunar vortex]

which are obviously not universally applicable

and also ofc spoonfeeding in general is bad

[hushed spire]

okie we swap to the kernel stack now

now I need to figure out why CS and SS are being wonky 😭

[narrow storm]

What’s your STAR register set too

Because uhh

That’s probably what’s breaking it

[hushed spire]

probably

[narrow storm]

And your GDT being miss matched

[hushed spire]

uint64_t star = (static_cast<uint64_t>(0x18 | 3) << 48) | (static_cast<uint64_t>(0x08) << 32);
wrmsr(IA32_STAR, star);

[narrow storm]

and does this match with your GDT

uint64_t star = ((uint64_t)(0x18 | 3) << 48) | ((uint64_t)0x08 << 32);
it looks like you ripped this straight from me

but C++'d it

[hushed spire]

yes I did

[narrow storm]

your GDT should match in that case

Else it won’t work right

[hushed spire]

ah

yeah I don't have a 32-bit User Code segment

[narrow storm]

the CPU uses the values you program to assume parts of your GDT

And if you iretq you will fucking explode

Because they don’t match

I was exploding because I had dropped the | 3

Which only breaks AMD

But not Intel

[hushed spire]

ofc 🥀

[narrow storm]

So imagine the shock when others testing my shit

When it dosnt break

And then I Goto an Intel machine to test it

And it dosnt break

😭

I fucking hate syscall/sysret

[hushed spire]

[narrow storm]

(For context I main an AMD system)

Also for some fucking reason

This broke on my machines QEMUS

But not on my laptops QEMU

Which also runs AMD

And it’s also zen3

Both running arch based distros up to date

[hushed spire]

[narrow storm]

Let’s just say

I really fucking hate these instructions

[hushed spire]

are these supposed to be OR'ed with 3?

I presume yes?

[narrow storm]

Yes

GDT entires are 8 bytes

The bottom two bits represent the CPL

[hushed spire]

okie then they're correct :3

[narrow storm]

Because it’s always aligned

Yada yada etc

[hushed spire]

I hate my life 🥀

was debugging for like, an hour, just to find out I was using the wrong path in image.sh 😭

works now tho

Now I need to make the scheduler... actually schedule

A simple scheduler should be pretty trivial

I'm calling it there for today tho

[hushed spire]

Works on my laptop as well!

[narrow storm]

Make a proper build system 😭

[hushed spire]

I dunno how I would go about having an image file build target for meson

[narrow storm]

You wouldn’t do it in meson

Meson builds the executable

You put a later onto top

[hushed spire]

[narrow storm]

You can make a shell script or a makefile that runs shell scripts

And that calls into meson to make the kernel

And the system that makes an initramfs

And then makes an ISO or whatever

And then calls QEMU

So it’s just make run

It compiles everything with meson and runs the build shit

And opens QEMU instantly

[hushed spire]

OHHH. Good idea

[remote junco]

Im like… 99% sure an instruction existed for pushing and popping everything

pusha iirc

[dense veldt]

not in long mode

[remote junco]

Ooh, didnt know that

[remote junco]

Ooh

Thought pusha was in long mode ngl

[serene lake]

yeah you'd expect a pushaq or pusha64

[dense veldt]

Ig it wasn’t worth it considering there are 8 more gprs

• tbh the only use for this instruction is in space confined code

Like the mbr

There are few places you want to push all gprs

[remote junco]

makes sense

[dense veldt]

the only one I can think about is an interrupt/syscall handler

but even then

it's just not worth it

[narrow storm]

It’s also not that much code size to do it

[narrow storm]

Debugging?

You want to be able to capture state

And fork() also needs you to save all registers

[dense veldt]

I mean

again

[remote junco]

i think they meant not worth its own instruction

[dense veldt]

you are in long mode

[visual walrus]

i think pusha might cause some trouble sometimes

[dense veldt]

you have the code space

[visual walrus]

from what i read, it also pushes rsp

[narrow storm]

Yes it does

[dense veldt]

in something like the mbr

[narrow storm]

💀

[dense veldt]

pusha is fucking invaluable

[dense veldt]

yep

[visual walrus]

pushing rsp is very bad sometimes

[dense veldt]

popa ignores it btw

afaik

[visual walrus]

BRUH

[narrow storm]

Why dosnt it also push the RIP for the lols

[dense veldt]

I have no clue why it pushs the sp

[visual walrus]

it's so bad

especially for interrupt stuff

[dense veldt]

ig it was useful to have the sp of the start of the pusha frame?

but even then

what?

[visual walrus]

?

[dense veldt]

this instruction is just confusing

[narrow storm]

Alignment

[dense veldt]

I could see stack alignment??

but still

[visual walrus]

yeah

[dense veldt]

that makes no sense

why push esp?

this also

ufguhifghurfghufg

fuck intel

[narrow storm]

It’s technically a GPR too

[visual walrus]

i avoided it for that reason

[dense veldt]

in the most annoyingly correct way ugh

I mean okay

the instruction does fault if esp contains 7, 9, 11, 13, or 15

sooooo

😭

[visual walrus]

tf

[dense veldt]

tldr

intel worded it fucking poorly

what I assume they mean

is if sp is not aligned to 8 fault

[visual walrus]

then why 11, 13 or 15?

[narrow storm]

So I can’t use address 13000 for my stack?

Which is aligned

[dense veldt]

idk 😭

[dense veldt]

no...

[visual walrus]

that instruction is so bad

[dense veldt]

hmmm

i wonder why intel decided to drop it in long mode

🤔

[dense veldt]

2*

not 8

im stupid

[visual walrus]

there still is something like that i think

[remote junco]

thats what i was abt 2 say lol

[narrow storm]

AMD*

[visual walrus]

ok no there is not

[narrow storm]

And it’s because it wasn’t worth it

When you can push registers by themselves

[dense veldt]

fuckfuckfuckfuckfuckfuckfuckfuckfuckfuckfuckfuckfuckfuckfuckfuckfuckfuckfuckfuck

I was wrong on the internet

[narrow storm]

And it’s probably easier to optimize many seperate register pushes

[dense veldt]

3:

[remote junco]

was gonna word it along the lines of "if the least sig bit is set, it faults (from what i see)"

[hushed spire]

probably gonna work on the build system some

[hushed spire]

also apparently when an exception occurs in userspace we crash and burn

that's certainly not supposed to happen

[narrow storm]

You need to check if it happened there

And then kill the process

Similar to the kill syscall or so

Though if your just starting out with userspace it’s a good thing imo to be able to catch the fault right there tbh

[hushed spire]

no like I triple fault, doesn't even get to the exception handler :p

[narrow storm]

Do you not have an RSP0 in your TSS?

Or IST for double faults?

You have your TSS working right

[hushed spire]

RSP0 should be set, but I suppose I can check

actually wait

no

I don't think it is

:p

lemme fix that

[narrow storm]

💀

[hushed spire]

okay yeah it works fine now

[visual walrus]

XD

[visual walrus]

each thread should have its own rsp0 btw

[hushed spire]

ye they do

[visual walrus]

do you update it in the tss, right?

[hushed spire]

yes

[visual walrus]

perfect

also another thing, use different ISTs for NMIs, exceptions and some other interrupts

if you aren't already

remember to allocate those ISTs in the TSS too

[hushed spire]

it's uh, very scuffed

but it does technically work

[narrow storm]

If it works it works

[hushed spire]

I'll fix it when I get off break lol

[narrow storm]

Tbh I can’t even tell what’s wrong with it so

[hushed spire]

it's moreso on the code side

[narrow storm]

Ah

Were you considering a rewrite at some point?

[hushed spire]

This is the rewrite 🥀

[narrow storm]

Ah

💀

Welp

You got to a working userspace

That’s a good job

[hushed spire]

[hushed spire]

ah, case and point, it doesn't work under KVM

[visual walrus]

F

[narrow storm]

💀

Lmfao

Does it work on real hardware

[hushed spire]

uhhh, lemme check

[visual walrus]

i don't think it will

lol

[narrow storm]

I mean

I wanna see how hard it blows up lol

[visual walrus]

XD

[hushed spire]

Yeah no

[visual walrus]

just a pagefault, f

[hushed spire]

okay I'm going to try and write a terminate syscall

which I presume I'd need some way of knowing what process a thread belongs to

[narrow storm]

Would this be for killing the current process?

[hushed spire]

I suppose I could just store a pointer to the process in the thread struct?

[hushed spire]

yeah

[narrow storm]

Yes

[visual walrus]

why not port mlibc

and implement those syscalls

it should work better

[narrow storm]

does this have anything to do with mlibc?

[visual walrus]

well, it would give them the args they should expect in that syscall

it would make it easier to fully port later

[narrow storm]

exit(int exit_code)

there done

thats pretty much it iirc

[hushed spire]

what are mlibc's sysdeps anyhow

[marsh pecan]

my kernel doesn't

[visual walrus]

this yes

i just save the parent PID in the thread struct, lol

[hushed spire]

so uhhhhh

been a while

took a lil break

probably not gonna do anything major atm but I will go around fixing some stuff

I'll also probably end up messing around with object management some

[hushed spire]

ugghhhhh

well ig I can't just wait around all day and hope and pray I get the motivation to work on this

:p

so uhhh

objects it is ig :p

[hushed spire]

blkvhajklfad

I still haven't done anything 😭

gonna try and get xbstrap setup either today or tmrw

[hushed spire]

oh yeah, also gonna see if I can try to understand the FreeBSD VM stuff

wish me luck :p

[halcyon helm]

I wish you luck

[lunar vortex]

study netbsd instead

[hushed spire]

oh?

any specific reason as to why?

[lunar vortex]

netbsd's UVM is really good

[hushed spire]

ah true, I do recall hearing something about UVM

[lunar vortex]

freebsd's is good but it still does old shitty unix stuff like shadow object chains

for cow

actually at your level i wouldnt even try reading that code honestly, id rather read a generic book on whatever OS interests you

[hushed spire]

fair

[lunar vortex]

freebsd design and implementation is pretty good

[hushed spire]

yeah I was def gonna read that, if I can keep my attention for long enough

[hushed spire]

alright

gonna try and figure out xbstrap

let's see how long this takes

debating whether or not I should put the kernel into it's own separate repo, or just keep everything in one big repo

[golden wyvern]

Separate repo is definitely a good idea

You want to be able to compare different versions of the kernel against userspace if debugging for example

It also just reduces pollution in commits

[fresh knoll]

yoo hows the os going

[hushed spire]

alright

working on the schdeuler rn

[fresh knoll]

w w

my bad internet doesnt allow me to build snow os

[hushed spire]

oof

[hushed spire]

methinks I should probably add support for kernel threads

I only have userspace ones atm

[hushed spire]

honestly I think imma just rewrite the scheduler/process creation stuff :p

[fresh knoll]

also you should fix your git repo because it errors out

compiling on linux doesnt work

[hushed spire]

frick

Ofc it doesn't

[fresh knoll]

it dont work on linux btw

[hushed spire]

Haven't worked on this in a bit :p

anyhow

we schedule threads now (again)

kernel threads anyhow

I mean user threads will also work

but rn the scheduler just blindly assumes all threads are of the same privilege level so

did what I just say make any sense?

idk

I don't think it did

anyhow

no wait