Nyaux

[flat nymph]

No

You have two threads

[surreal path]

what

[molten grotto]

I feel like you should stop and just think for a moment what exactly do you want to do when switching between two threads

and don't tie that code to interrupts/syscalls in any way, just have a function you can use to switch between two threads

[surreal path]

yea i save ctx, load ctx, switch pagemap

[flat nymph]

I'm back

[flat nymph]

And you switch kernel stack

Well, saving and loading ctx is part of that kinda

Or rather you save the kernel stack when you save ctx, and you load differen't thread's kernel stack when you load it

[molten grotto]

; void do_sched(Thread* old, Thread* new)
do_sched:
    ; save callee saved registers to the old thread's stack
    push rbx
    push rbp
    push r12
    push r13
    push r14
    push r15

    ; save rsp inside old thread
    mov [rdi + Thread.saved_rsp], rsp
    ; load rsp from new thread
    mov rsp, [rsi + Thread.saved_rsp]

    ; restore saved regs from the new thread's stack
    pop r15
    pop r14
    pop r13
    pop r12
    pop rbp
    pop rbx
    ret

something like this is what you want to do

[surreal path]

what so i need 2 FIELDS in interrupt context now

one for the thread stack

and one for the kernel stack

[flat nymph]

So you have something like this ```c
void switch_thread(thread *new_thread) {
struct sse_data sse;
struct gs_stuff gs;
save_sse(&sse);
save_gs(&gs);
if (new_thread->cr3 != my_cr3())
load_new_cr3(new_thread);

do_sched(new_thread);

restore_gs(&gs);
restore_sse(&sse);
}```

[surreal path]

bro this is pain

[surreal path]

sir why are u saving gs

u have context

and like idk why ur saving gs

[flat nymph]

Wdym

[molten grotto]

because the gsbase may be modified by the userspace using a syscall?

[surreal path]

nvm

[thorn bramble]

assuming one has such syscall

[surreal path]

so

[thorn bramble]

[flat nymph]

Potentially add more context saving functions

[surreal path]

is that why i need 2 FIELDS

[molten grotto]

one for the stack pointer that you load at the start of syscall (or put in the tss rsp0 field) and one where you save the kernel rsp when switching yes

[flat nymph]

Kernel stack is part your Thread

Or a second field

You don't change user stack

[flat nymph]

No such field

[surreal path]

yea okay so suddenly i need to save it

fun!

[flat nymph]

You save it to kernel's stack when you get interrupt

[surreal path]

what the moment after i get a scheduling interrupt?

after saving gps or wtv

[molten grotto]

you just call your generic switching function inside there

[surreal path]

so how do i load gps

if i load a new stack

[molten grotto]

.

[flat nymph]

No

[surreal path]

he said no qwinci

[flat nymph]

I mean you call it from my function

[surreal path]

ur code is wrong

[molten grotto]

no its not

[molten grotto]

yes

[surreal path]

what if there wasnt any gps on that stack saved to begin with

[flat nymph]

That's not possible

[surreal path]

how

[flat nymph]

You build it when you create a new thread

[surreal path]

fun

[flat nymph]

After that, it will always have the context of the previous thread

[molten grotto]

when you initially create a thread you set the rsp inside the thread struct to point that much lower to the stack yeah

[surreal path]

so when creating a new thread

how am i supposed to build it exactly

when creating these gps

on that kstack

[molten grotto]

you just set the saved rsp field inside the thread to be the stack top - the amount of space the registers that you expect to be on the stack

[surreal path]

no i mean i will have to manually push values

[molten grotto]

yes?

[surreal path]

not only this but I ALSO have to save gs now

[molten grotto]

its just a matter of doing *--thread->rsp = 0 (assuming the rsp field is a u64*) how many times you want to push

[surreal path]

before swap gsing

[flat nymph]

No , this is what everyone does

[flat nymph]

No

Userspace gs

[surreal path]

yea userspace gs

BEFORE swapgsing

[flat nymph]

After swapgs

[flat nymph]

No

[surreal path]

ok so u want me to read kernel base msr

in asm

[flat nymph]

syscall:
swapgs
load kernel stack
push all registers
call syscall
pop all registers
swapgs
sysretq

[surreal path]

this is not for syscall

this is for interrupt

task switching

[flat nymph]

Same, but withoug loading kernel stack

[surreal path]

stop assuming i have syscall guys

😡

[surreal path]

no qwinci said i need to save and load thread kstacks

[flat nymph]

if (coming from userspace)
swapgs
push all registers
call isr
pop all regisers
if (returning to userspace)
swapgs
iretq

[flat nymph]

No

[molten grotto]

interrupts are unrelated to task switching

[surreal path]

^

this is task switching

[flat nymph]

Yes

[surreal path]

my task switching is interrupt based

[flat nymph]

No

[molten grotto]

don't do that

[surreal path]

WDYM dont do THAT

BRO

[flat nymph]

You task switch when you decide that you want to run a different thread

[surreal path]

I HAVE A LAPIC TIMER THAT FIRES ISR 32

every 10ms

AND I SCHEDULE

[molten grotto]

you can use your task switch function inside the interrupt but it shouldn't be tied to it, you should be able to call it anywhere

[flat nymph]

You call switch_thread(new_thread)

boom

You've switched the context

Now new thread runs

It can be from syscall

It can be from interrupt

[surreal path]

fuck u when a syscall happens im not switching the thread

[flat nymph]

Which includes timer interrupts, page faults, anything you want

[flat nymph]

You will be

[surreal path]

no

[flat nymph]

I give up

[surreal path]

why do i need to

lmao

💀

[flat nymph]

Forget about timer interrupts

[flat nymph]

Everything will work out when you do that

Now just implement syscalls

No timer for you

[surreal path]

why do u want me to switch threads during a syscall

yes its wasted compute time

but again

[flat nymph]

No

[surreal path]

ok what is it then

[flat nymph]

It's wasted compute time if you don't

[surreal path]

yea

[flat nymph]

pthread_mutex

[molten grotto]

you can eg. acquire a futex or whatever, then if the futex is acquired you want to switch to some other thread

yeah

[surreal path]

[molten grotto]

its stupid to tie task switching to interrupts

[flat nymph]

Your timer interrupt should just call a c function

[surreal path]

it doea

does

[flat nymph]

Where you find a next task

[surreal path]

mhm

[flat nymph]

And call this

with the new task

If you want to switch from a syscall, you also call this function

[surreal path]

and then what

i have to switch kstacks

save and load kstack

when switching threads

doesnt matter if its from syscall or interrupt

[flat nymph]

This is all you have to do

[flat nymph]

Yes

[surreal path]

yea i dont see any saving and loading of kstacks

[flat nymph]

Because it's the same function

If you don't switch threads, you don't load new kstacks

[surreal path]

mhm

[flat nymph]

so, in your timer interrupt function

You

• save all registers to stack
• call C
• restore all registers from stack
• iretq

[flat nymph]

If your timer isr decides to reschedule, it calls this (from C)

[surreal path]

ok so when swithcing threads i must

mov [oldthread.kstack], rsp
; switch threads
mov rsp, [newthread.stack]

[flat nymph]

You're returning to a different task

[surreal path]

pesudo code btw

[molten grotto]

yes like the do_sched function that I sent does

[surreal path]

ok fine

like hold on

[molten grotto]

(that's used by the code that mishakov sent)

[surreal path]

i have to create 2 INLINE ASM

lines

man i hate c inline asm

[flat nymph]

And you always call that from switch_thread

[flat nymph]

No

Don't use inline asm

[flat nymph]

Create a new nasm file, and paste this code

[surreal path]

ugh

fine

no nvm

it will be easier to do inline asm

as arch abstraction shit

[molten grotto]

you already have asm files tho and they are arch specific

[surreal path]

ITS FINE okay ill js make the inline asm volatile so compiler doesnt mess with shit and try to add nostack or wtv

yea

but they call non arch specific code

not get called by non arch specific code

[molten grotto]

why does that matter

[surreal path]

bcs it does

js let me use inline asm lmao

[molten grotto]

at least make it global inline asm then and not inside a c function lol

[flat nymph]

wtf

Also

union thread {
struct thread t;
uint64_t kernel_stack[2048];
};

Probably

[surreal path]

no thanks

ok now on thread create i must put the ctx in the kstack

TIME TO DO THIS MANUALLY

wait i have a better idea

better idea done

😎

-= whoops

and i should -= before

then load the value

done

opinion on this masterpiece of code

😎

now according to my calculations this should work

SO CLOSE

ugh

so its that function

[flat nymph]

Wtf

No

[surreal path]

why

[flat nymph]

You're doing it wrong

[surreal path]

tell me

how am doing it wrong

[flat nymph]

Remove these functions

Replace them with qwinci's code

[surreal path]

no?

what

this is for

creating the kentry thread

???

like bru

[flat nymph]

No

[surreal path]

wdym no?

[flat nymph]

Have you implemented this?

[surreal path]

done via inline asm yes

[flat nymph]

Show it

[flat nymph]

I don't see

; void do_sched(Thread* old, Thread* new)
do_sched:
    ; save callee saved registers to the old thread's stack
    push rbx
    push rbp
    push r12
    push r13
    push r14
    push r15

    ; save rsp inside old thread
    mov [rdi + Thread.saved_rsp], rsp
    ; load rsp from new thread
    mov rsp, [rsi + Thread.saved_rsp]

    ; restore saved regs from the new thread's stack
    pop r15
    pop r14
    pop r13
    pop r12
    pop rbp
    pop rbx
    ret

[surreal path]

bro timer interrupt saved the registers

[cinder plinth]

sorry but

[surreal path]

oh

wait

[cinder plinth]

I hate your colorscheme so much

[surreal path]

i agree

is cringe

[flat nymph]

It saves userspace registers

You need to be saving kernel registers

as well

[cinder plinth]

probably why you get so many bugs

good colorscheme == less bugs

this is a known fact

[surreal path]

fine

[flat nymph]

wrong

I've been using white color scheme and didn't have bugs

[cinder plinth]

no it's true

there are good light colorschemes tho

like solarized light

or ayu-light

[flat nymph]

Bugs burn when they touch lightbulbs

[cinder plinth]

gruvbox light isnt that bad either

[surreal path]

ok now somethings starting to break my brain

if we are loading kernel registers and saving them

what about

the registers we saved at the start of the timer interrupt

the userspace ones

[flat nymph]

You save them to kernel stack

[surreal path]

[flat nymph]

Which is one per userspace thread

You then switch kernel stacks/contexts

The cpu now has different thread's stack in its %rsp

You restore registers from the stack

The kernel stack for the different thread has its registers saved

So you restore registers of a different thread

[surreal path]

what stack do we load at the start of the isr

if its the one from ist

we are just loading some rand kstack

when we enter an interrupt

then we save those values???

??????????????????????????????????????

[flat nymph]

You also change stacks in TSS

So the right thread's kernel stack is always loaded in isr

[surreal path]

bro

now i need a tss

and an isr

fuck u man for making me do all this work

specifically

[flat nymph]

Or wherever

I don't remember

Where does kernel get its stack on interrupt

From there

[surreal path]

i currently dont even have an isr

[flat nymph]

What

You have IDT

[surreal path]

ist*

my bad

[flat nymph]

Sorry I didn't invent x86

[surreal path]

yea why does x86 make everything so annoying

;no

ugh

so now i need

a tss

an ist

for a seperate kstack

then after saving userspace regs

i need to save kstack regs

[flat nymph]

Ist?

[surreal path]

kernel*

[surreal path]

interrupt stack table

so now i need to create like 2 kstacks

one for the interrupt on entry

and one for the threads kstack

[flat nymph]

No

[surreal path]

wdym no???

[flat nymph]

One stack

[surreal path]

and i need to somehow set the ist value to the current thread???

tf

[flat nymph]

Which you load into rsp0 (?)

[surreal path]

into rsp0

[flat nymph]

Forget about ist

[surreal path]

bro

into rsp0

fucking hell

i need to somehow

already be in a thread

change out rsp0

fucking hell bro

[flat nymph]

Idr

One of them

Maybe not

I'm eating and on my phone

Rtfm

[surreal path]

im reading the fucking manual chill

whats cringe is that i have to do all this housekeeping for what

so annoying

[flat nymph]

You do it once and forget about it

I haven't touched my TSS in 2 years

[surreal path]

save userspace regs, when switching tasks save kernel regs. switch out rsp 0. switch out rsp, load kernel regs, when in intererupt or syscall or whatever reload userspace regs iretq

or sysretq

or wtv

then do it all out again

yea im taking a nap no1

no2 im doing this when i wake up

not in the mood rn

x86 is cringe for this

[finite summit]

I just have rsp0 set to a per-cpu specific stack

and not to a per-thread stack

then I do have a per-thread kernel stack

but that's for syscalls only

    swapgs
    mov r10, rsp
    ; Switch to a temporary stack
    mov rsp, [gs:0xc8]
    add rsp, 0x20000

    push rdx
    mov rdx, [Arch_KernelCR3]
    mov cr3, rdx
    pop rdx

    ; Switch to the thread's 'proper' stack
    mov rsp, [Arch_cpu_local_currentKernelStack_offset] ; hacky, but works
    mov rsp, [gs:rsp]
    add rsp, 0x10000```

the reason I first switch to a per-cpu temporary stack is because I didn't want to map the per-thread kernel stack into that process' CR3 (I do kpti)

[flat nymph]

You use different kernel mappings per process?

[finite summit]

not quite

I do kernel page table isolation

to only map the bare minimum of the kernel into a process' context

the bare minimum is anything needed by isr handlers and the syscall handlers

which are stuff like, per-cpu temporary stacks, idt, gdt, etc.

[finite summit]

as well as the function CoreS_SwitchToThreadContext

which switches to a thread context

[surreal path]

hi i woke up but im still gonna take a break for a few hours

mood swings ig

[rigid fable]

tho, is it part of the codebase typing everything without having proper spacing between lines?

[surreal path]

i blame my editor

someone give me vscode settings that doesnt cause this

or a better code editor idfk

[molten grotto]

you could just format them in a sensible way yourself

[surreal path]

no

talks cheap

send patches

[molten grotto]

the style is also inconsistent within the codebase, somewhere 2 space tabs are used (ew) and others proper tabs

[surreal path]

fix my formatting qwinci

i sentence you to fixing my formatting

/j

[molten grotto]

sure

[surreal path]

😭

nah if u actually do fix it ill try to actually keep consistent formatting

for once

cause id feel bad

[cinder plinth]

use clang format

and format on save

[molten grotto]

yeah that would be an option too, though sometimes it creates weird looking code that's far from perfect

which is why I don't really use it, I just write code with sensible formatting to begin with

[silver yarrow]

its not just the formatting

the erratic naming makes things difficult to follow

and lack of defining constants

[surreal path]

good point

[finite summit]

serenity

[surreal path]

going forward ill try to use naming

proper

and proper constants

im not gonna go into the codebase and change the existing naming however thats too much work and i have a lot to do today

with the nyaux kernel itself

likkkeee actually having a tss

and

adding all that shit mr @flat nymph wants

because its what everyone does lol

anyways we start programming

so looking at the tss

it seems to be 100 bytes long?

weirdly

weird number but ok

well no

its 100 * 4

400 bytes?

wiki makes it confusing

[molten grotto]

its 104 bytes

[surreal path]

okay

so uint32_t

26

26 entries

[rigid fable]

do you have some kind of extension/setting related to code formatting on save?

[surreal path]

no

[surreal path]

sorry 27?

is htis correct?

27 uint32_t entries

??

[molten grotto]

;cpp << (27 * 4)

[viscid pecan]

Program Output

108

qwinci | 58ms | c++ | x86-64 gcc (trunk) | godbolt.org

[surreal path]

oh

so 26

okay got it

[rigid fable]

It's not even on of these right? (sorry if i'm interrupting you from the other stuff you're doing)

[surreal path]

its on now

time to make a gdt entry describing my tss

[rigid fable]

mh

[surreal path]

page for linear address is dead

im guessing a physical address?

[molten grotto]

no its virtual address

[surreal path]

oh okay

thanks for osdev wiki for giving me the access byte i needed

0x89

flags should be empty

limit is the size of the tss

okay lets get cooking

[cinder plinth]

ayu dark spotted

based

[surreal path]

okay so

i might need 2 entries to describe the tss

in the gdt

i just realized its a 128bit entry

so i need 2 entries

lower half first higher half second

[rigid fable]

actually

[cinder plinth]

"About
Combination theme for VS Code and VSCodium that inspired from Ayu Theme, Monokai , Andromeda, Material Color, and Gruvbox Darktooth Color."

[surreal path]

okay i constructed this

i know i will need to do some bitshifting if i want to or this

but thats good

nevermind

because for SOME reason

x86 thought it would be a good idea

to have base seperated into 5 PIECES

cringe

wait no thats limit

im idiot

[thorn bramble]

just tame it with //

[molten grotto]

eh I don't want to do that every time I construct an object using a designated initializer

[surreal path]

okay

so this is for the first tss system segment descriptor entry

[thorn bramble]

is it cpp const auto my_object = Object{ xxx, yyy, zzz };

vscpp const auto my_object = Object{ xxx, yyy, zzz, };
?

if so, trailing comma

[surreal path]

now for the second entry

that should be the 2

time to add the entries into the gdt and try it out

wheres my __builtin_trap()

we will check if this works

it does

okay

mmm

thats bad

it says my tss is still busy

tf

WHY IS MY TSS STILL BUSY

😭

[cinder plinth]

zig moment

[thorn bramble]

thjat's c++ lol

[surreal path]

uint64_t tssaddress = (uint64_t)&tss;
uint16_t base_low = tssaddress & 0xFFFF;
uint8_t base_mid = (tssaddress >> 16) & 0xFF;
uint8_t base_midhi = (tssaddress >> 24) & 0xFF;
uint32_t base_hi = (tssaddress >> 32) & 0xFFFFFFFF;
uint8_t access_byte = 0x89;       // stolen from osdev wiki cause im lazy to construct my own
                                   // basically what it means is it describes the tss as avabile and stuff
uint64_t constructedlow = ((uint64_t)base_low << 16) | ((uint64_t)base_mid << 32) | ((uint64_t)base_midhi << 56) access_byte | sizeof(tss) - 1;

uint64_t constructedhi = (uint64_t)base_hi;
gdt[9] = constructedlow;
gdt[10] = constructedhi;

okay so this is my constructed shit right

it still thinks its busy

which makes no sense

and the bases are all bitshifted correctly

[cinder plinth]

yeah but zig does that too iirc

trailing commas

[surreal path]

maybe the size cannot fit in 16 bits

but i doubt it

hold on\

yea it can fit

time to print the entries in binary

and go over it

@molten grotto whats the nanoprintf's binary %

if u know

i swear there is one

[molten grotto]

that (also with functions) and ```cpp
inline constexpr Ps2Cmd RESET {
.cmd = 0xFF,
.params = 0,
.ret = 2
};

[surreal path]

??\

[molten grotto]

just wait a moment lol

[surreal path]

okay lol

[molten grotto]

its the same as in ansi c, %b

though you need to define NANOPRINTF_USE_BINARY_FORMAT_SPECIFIERS

[surreal path]

okay hold on

[thorn bramble]

same, trailing comma

[surreal path]

@molten grotto i changed that NANOPRINTF_USE_BINARY_FORMAT_SPECIFIERS

lub got

[molten grotto]

lub is not a valid format

[surreal path]

oh

[molten grotto]

u is a specifier on its own

you can't combine it with b

[surreal path]

okay so if i want to print a uint64

in binary

[molten grotto]

%lb

[surreal path]

thanks

so

this is the entry for constructed low

hold on

js fixed my leds

SO BACK TO WHAT WE WERE SAYING

0000000010001001

thats the limit

137?

thats the size of the tss

how???

its 26 entries

[edgy pilot]

you forgot e at the end

[surreal path]

lol

[surreal path]

@molten grotto is that bad

[edgy pilot]

why not just make a struct

[surreal path]

the bytes of a tss should be 108

;cpp << (26 * 4)

[viscid pecan]

Program Output

104

linuxmaster2.0 | 37ms | c++ | x86-64 gcc (trunk) | godbolt.org

[surreal path]

yea i think i need to be the array packed

I CANT MAKE IT PACKED

BRO

so the gdt is right

[edgy pilot]

struct tss
{
    u32 reserved
    u64 rsp[3]
    u64 reserved
    u64 ist[7]
    u64 reserved
    u16 reserved
    u16 iopb
} attribute packed

[surreal path]

but not me

ugh fine ill make a struct

[edgy pilot]

why ugh

[surreal path]

sorry.

sorry about that

[edgy pilot]

array is the worst way
just a tad better than manually entering each byte

[surreal path]

i dont know why i keep saying ugh

my bad

im sorry ilobilo

okay im doing it @edgy pilot

[edgy pilot]

smh

[surreal path]

why are you saying smh 😭

[edgy pilot]

u64

reversed

[surreal path]

OH LOL

wait no?

0x04

[edgy pilot]

low high u32 is just one u64

[edgy pilot]

just copy this

[surreal path]

wait yea i know what to do!!!

okay @edgy pilot

[edgy pilot]

huh

[surreal path]

thats the tss now

[edgy pilot]

not u8

[surreal path]

why?

oh right

nvm

now its ready

[edgy pilot]

the comment is incorrect too

[surreal path]

fixed

[edgy pilot]

good job
now you can run Minecraft

[surreal path]

😭 😭

[edgy pilot]

doom first

[surreal path]

yes ofc

will this be zerod out

i suppose it would be

YESS

ITS 104

tss is still busy 😔

[edgy pilot]

{ 0 }

[surreal path]

STILL

after i did that

[edgy pilot]

I know

that wouldn't fix it

[surreal path]

yea so whats going on

[edgy pilot]

idk

you are in a VC with some pretty smart people

[surreal path]

i cant speak im sick

[edgy pilot]

I can't sick I'm speak

[surreal path]

bru

yea its correct

yea they are not answering

@molten grotto do u know whats going on

[molten grotto]

I can try to help after I finish ow match

[surreal path]

okayokay

[molten grotto]

did you load the tss with ltr @surreal path

[surreal path]

OHHHHH

what value should i give the tss @molten grotto

its address?

[molten grotto]

where

in ltr?

[surreal path]

yea

[molten grotto]

the offset of the tss entry in the gdt

[surreal path]

okay

okay so 0x80

bro

[molten grotto]

you have 17 entries in your gdt?

[surreal path]

12

[molten grotto]

then how can the offset of the tss entry be 0x80

[surreal path]

okay then its 0x96

but again

[molten grotto]

that's even more lol

[surreal path]

its saying

[molten grotto]

iirc its ltr [offset]

[surreal path]

thanks

[molten grotto]

fix the offset first tho

like what is the byte offset from the start of the gdt to the tss entry

[surreal path]

it died because u tried to dereference 0x96

so it has to be

rdi + 0x96

[molten grotto]

no

and that offset is still wrong

[surreal path]

so its 0x72

[molten grotto]

its in decimal not hex

[surreal path]

hold on

0x48

from the gdt to the offset

yea

[flat nymph]

I'm doing ltr %ax

[molten grotto]

oh yeah I misremembered 💀 that's how you are supposed to do it, you move the offset to a register and then do that

[surreal path]

okay

wheres tss

is that a good thing that its no longer busy @molten grotto

and it isnt even there

in the qemu log

[molten grotto]

what is the asm that you use to load it rn (just to make sure)?

[molten grotto]

that would do ltr *(uint16_t*)(rdi + 0x48)

swap that to mov eax, 0x48 and ltr ax

[surreal path]

why ax

why are you not giving it the 32 bit register but half of it

16 bit

[molten grotto]

ltr takes in a 16-bit r/m

[surreal path]

r/m?

[molten grotto]

register or memory

[surreal path]

okay

[molten grotto]

meaning it either takes in a 16-bit register or a 16-bit memory location to load the offset from

[surreal path]

okay

okay now it 0xd'd

tss is still busy

it does it when loading the tss

[flat nymph]

How do you load gdt

Do you give it the right size

[surreal path]

yes

[molten grotto]

it looks like you aren't setting the limit?

[surreal path]

oop

forgot

hold on

done

ITS STILL 0xD'ING

[molten grotto]

the entry is still wrong, Ill leave it as an exercise for you to figure out how

[surreal path]

okay

hmmm

yea thats completely wrong

oh right

i didnt shift the access byte

my bad

yea this is correct

lets go

we have a tss now

[flat nymph]

Btw, you need a TSS per CPU

[surreal path]

dw i have that covered

wait

oh

that means i need a gdt per cpu

as well

[molten grotto]

no

[surreal path]

fucking hell

[molten grotto]

you can reuse the gdt entry

the cpu doesn't care about the gdt entry after ltr

[surreal path]

no because the address will be totally different per cpu

[molten grotto]

you can just set the address, do ltr and then switch the address

[surreal path]

because i have to put it in a per cpu data struct

[molten grotto]

as long as you guard the gdt entry setting + ltr with a spinlock so the cpus don't try to modify the entry at the same time

[surreal path]

????

[surreal path]

what

[flat nymph]

Probably

[surreal path]

yep

[flat nymph]

CPU caches gdt entries

Anyway, it doesn't matter

[surreal path]

i have an idea

kmalloc a tss structure

[flat nymph]

Why

[surreal path]

and then

[flat nymph]

I mean you can

[surreal path]

have per cpu data

have a pointer to that

so it will be per cpu

as u wanted

[molten grotto]

how does that help with anything

[flat nymph]

Or you can just put it there directly

[molten grotto]

^

[surreal path]

fine

i will have to reinit the gdt for the bsp

anyways

[flat nymph]

It's 3 extra lines of code

[surreal path]

i know

ok there

okay so

its 0xding at line 13

i set the last two values where there would be a tss segment descriptor to 0

that shouldn't be a problem right?

[flat nymph]

Just set it in C

[surreal path]

no thanks

[molten grotto]

do you pass the second arg as 1

[surreal path]

no

hold on

if its true

i pass in 1

or well

a bool

thats just really 1

tbf

[molten grotto]

then its going to try loading the null tss entry on the bsp

[surreal path]

why??

[molten grotto]

because you pass true to gdt_flush?

oh wait its reverse nvm

[surreal path]

no but i skip the load

[flat nymph]

Why do you even pass it?

[surreal path]

doesnt rlly matter

js

dunno whats going on

the tss entries are null

i skipped the load

why is cpu mad

[flat nymph]

Yes?

[surreal path]

and it will skip the load

[flat nymph]

You're giving it null entries

[surreal path]

okay then what am i supposed to do, how do i tell mr cpu theres no tss atm

[flat nymph]

Why are you skipping it

[flat nymph]

You don't

[surreal path]

because this is for on init

before anything

[flat nymph]

Just initialize it

[surreal path]

like the moment u

Bro

💀

[molten grotto]

you should have the tss for the bsp at that point

[surreal path]

no

okay

so

in main.c

[flat nymph]

You don't need gdt for kmalloc

[surreal path]

arch init is loaded

init gdt is given true

meaning it will skip the load

so it skips the load

i have a hacky solution

[molten grotto]

or you can statically allocate the cpu struct for the bsp cpu

[surreal path]

no

[flat nymph]

But that wastes 104 bytes of RAM

[surreal path]

i have a better idea

im statically allocating another gdt

for the bsp

[flat nymph]

Unless you put it into init section which gets discarded

[surreal path]

initally

[flat nymph]

Wtf

[molten grotto]

I mean you are going to use the same amount of ram regardless whether you statically allocate it or use kmalloc

[surreal path]

^

[flat nymph]

Oh

Statically allocate BSP CPU struct

[surreal path]

no

[flat nymph]

Why not

[surreal path]

my solution wastes less memory

ok works now

[flat nymph]

This wastes less memory than kmalloc'ing it

[surreal path]

im not kmallocing anything

[molten grotto]

it doesn't waste any memory to statically allocate the bsp struct

[flat nymph]

You'll have to

[surreal path]

why

now its dying

when trying to use my new gdt

at ltr

when loading the tss offset

huh wtf???

ugh fine ill statically allocate it

huh???

WHAT IS GOIGN ON

NOW MEMORY BUGS??

WHAT

oh

IM DOING THIS

fucking end me

now we have UB

and bugs

and bug

and i have NO idea whats going on

@molten grotto i thought we solved the memory bugs

happening on line 163????

end me

end me

[flat nymph]

Btw, bsp's lapic id is not always 0

[surreal path]

oh then am i supposed to idendtify if i am bsp

[flat nymph]

Get if from limine

[molten grotto]

yeah the limine smp request contains the bsp id

[flat nymph]

And store it as a global variable or something

[surreal path]

fine

[molten grotto]

or you can just get it yourself on the bsp before letting the other cores to your kernel code

[surreal path]

I STILL HAVE NO IDEA WHATS GOING ON

I DID THAT

STILL UB

STILL BUGS

sometimes its a 0xd

sometimes its a 0xe

it doesnt care

its happening

when loading

the tss

BRO

yep my tss is creating ub

i want to die

well

its all pushed to github

and the rip is different each time so its ub

[edgy pilot]

?????????????????????

❓

❔

[surreal path]

I DONT KNOW WHATS GOING ON

[edgy pilot]

https://tenor.com/view/ratio-giff-gif-24757714

[surreal path]

literarly

[edgy pilot]

*literally

[surreal path]

bru

does anyone at all have an idea to what is happening

at ALL

[edgy pilot]

that's your job bru

[surreal path]

i legit dont know

i cant find anything useful

im just loading the tss

how is this causing ub

😭

[edgy pilot]

not everything is UB

[surreal path]

well this is

[edgy pilot]

ub means undefined behaviour

[surreal path]

yea

[edgy pilot]

skill issue isn't ub

[surreal path]

its ub

because

theres different things happening

on each reboot

so its def UB

[edgy pilot]

that's not ub

[surreal path]

yea its skill issue whatever u wanna say

[edgy pilot]

no, you are severely misunderstanding what UB means

[surreal path]

explain

[edgy pilot]

Undefined Behaviour, doing things in a language that have not been defined by the standard

not bugs in code

[surreal path]

then its not ub

[edgy pilot]

that's just bugs

[surreal path]

then its bugs

whatever

bugs i cannot figure out because on every reboot something is different

which makes no sense

and drives me insane

[edgy pilot]

it makes perfect sense

the state isn't exactly the same after a fresh qemu run

[surreal path]

oh my god

ur not understanding me

im not explaining this

[edgy pilot]

I am

this requires problem solving skills

[surreal path]

ur saying this like i dont have problem solving skills

[edgy pilot]

engage your brain and think, mark, THINK!

[surreal path]

why is everyone trying to insult me

first my dad

[edgy pilot]

nah you're just not using it

[surreal path]

my brothers

now this

[edgy pilot]

insulting is very different from criticising

[surreal path]

im starting to actually legit cry

so

im taking a nap

[edgy pilot]

good night

[surreal path]

goodnight

[surreal path]

ok i cant sleep

ill try to figure this out

okay

i caught something

ill add an assert

okay

there are 2 behavioras

that happens

this is the first one

[surreal path]

and the second is this

no idea

printing the value now produces consistent behavior

nvm

its not

so none of this happened before adding the TSS

but the tss shows

this is confusing

[silver yarrow]

what's going on

[surreal path]

no absolute idea

and im glad ur here

because i am struggling

ever since ive tried to add this TSS

its been causing me a TON of UB

[silver yarrow]

is the code on gh?

[surreal path]

yes!

[silver yarrow]

alrighty gimme a sec

[surreal path]

kk!

[silver yarrow]

@surreal path

[surreal path]

yea?

[silver yarrow]

the IOBP thing has to be set afaik

[surreal path]

set to what?

[silver yarrow]

the iobp base

to sizeof(tss)

[surreal path]

okay

ill set that

[silver yarrow]

ur saying the base is at the end of the tss

[surreal path]

how so?

[silver yarrow]

and the tss size tells it that the size of the map is zero

[surreal path]

explain further

[surreal path]

hold on

something like this

?

[silver yarrow]

yeah I am pretty sure u gotta do that

[surreal path]

okay i did that here

[surreal path]

how tho?

[silver yarrow]

by setting the base to sizeof(tss)

[surreal path]

i did not tho?base is the tss address

[silver yarrow]

the IOBP is the base offset

[flat nymph]

I'm not setting that

[silver yarrow]

hm

[edgy pilot]

I don't have it

[surreal path]

???

[edgy pilot]

afaik iopb is optional

[surreal path]

yea

[flat nymph]

This is what I'm doing

struct GDT {
    GDT_entry Null {}; // always null
    GDT_entry _64bit_kernel_code {0, 0, 0, 0x9a, 0xa2, 0};
    GDT_entry _64bit_kernel_data {0, 0, 0, 0x92, 0xa0, 0};
    GDT_entry _32bit_user_code {0xffff, 0, 0, 0xfa, 0xcf, 0};
    GDT_entry user_data_1 {0xffff, 0, 0, 0xf2, 0xcf, 0};
    GDT_entry _64bit_user_code {0, 0, 0, 0xfa, 0xa0, 0};
    GDT_entry user_data_2 {0xffff, 0, 0, 0xf2, 0xcf, 0};
    GDT_entry ring2_code {0, 0, 0, 0xda, 0xa0, 0};
    GDT_entry ring2_data {0, 0, 0, 0xd2, 0xa0, 0};
    System_Segment_Descriptor tss_descriptor;

    constexpr u16 get_size() { return sizeof(GDT) - 1; }
} PACKED ALIGNED(8);

struct System_Segment_Descriptor {
    u16 limit0;
    u16 base0;
    u8 base1;
    u8 access;
    u8 limit1 : 4;
    u8 flags : 4;
    u8 base2;
    u32 base3;
    u32 reserved;

    constexpr System_Segment_Descriptor(): System_Segment_Descriptor(0, 0, 0, 0) {}
    constexpr System_Segment_Descriptor(u64 base, u32 limit, u8 access, u8 flags)
        : limit0(limit & 0xffff), base0(base & 0xffff), base1((base >> 16) & 0xff), access(access),
          limit1((limit >> 16) & 0xff), flags(flags), base2((base >> 24) & 0xff),
          base3((base >> 32) & 0xffffffff), reserved(0)
    {
    }

    TSS *tss();
} PACKED;

c->cpu_gdt.tss_descriptor = System_Segment_Descriptor((u64)tss, sizeof(TSS), 0x89, 0x02);

[surreal path]

how are u liking the roblox gameplay @flat nymph

[flat nymph]

I'm not liking it

[surreal path]

lol

[surreal path]

i lit do what u do for creating the systemsegment descriptor

so no idea

[flat nymph]

Same access and flags?

[surreal path]

yep

[flat nymph]

Are you sure the problem is here?

[surreal path]

i have no idea

genuinely

[flat nymph]

How does it crash

[surreal path]

i said above here and #osdev-misc-0

[edgy pilot]

what does 0x02 in flags do there

[flat nymph]

I have no idea

[edgy pilot]

lol

this?

DB: Size flag. If clear (0), the descriptor defines a 16-bit protected mode segment. If set (1) it defines a 32-bit protected mode segment. A GDT can have both 16-bit and 32-bit selectors at once.

I don't think that would affect anything

[flat nymph]

I guess

Idk, it works

Hmm

So my TSS is broken?

[surreal path]

maybe idk

i have major ub

[edgy pilot]

it works right?

[flat nymph]

Yeah

[edgy pilot]

then it is not :p

[silver yarrow]

I am reading through the manuals and cant figure out how this works

afaik it cannot be "disabled"?

atleast the manuals dont mention this

[flat nymph]

Where does this happen?

[edgy pilot]

io access from userspace is disabled by default

[surreal path]

randomly

[edgy pilot]

you don't touch it if you don't want it enabled

[surreal path]

in this reboot it

happened when switching tss

[flat nymph]

Which line does it point to

[silver yarrow]

sure but what governs this

doesnt the iobp govern this

[surreal path]

ltr

in gdt.asm

[edgy pilot]

hmmmm

[silver yarrow]

like if u set it to zero

[edgy pilot]

I guess it being set to 0 disables it

[silver yarrow]

the manuals dont say this

arent u saying that the tss data essentially is iobp