QEMU Reboots on sysret

Question

I'm writing a small Kernel to learn more about Operating ystems. I recently decided to start implementing User Mode, just for fun. To achieve this, I followed this guide: https://blog.llandsmeer.com/tech/2019/07/21/uefi-x64-userland.html Unfortunately, though, I've seen nothing but gpfaults, page faults and reboots in the last 24 hours. I tried and retried, following many different guides, from the OSDev Wiki, to random blogs, and checking with Volume 2 of the AMD Programmer's Manual for x86-64, but nothing. It seems as though, instead of jumping to user_main, sysretq rejumps to kernel_main (Indeed, running the function twice results in the same weird page fault - with a random text output that should only be displaied once [at boot]). If i use sysret or o64 sysret instead of sysretq, QEMU outright resets.

I seriously don't know how to deal with this problem.

Links and references:

You can find my Kernel at: https://github.com/Alessandro-Salerno/SalernOS-Kernel The code for entering User Mode can be found at src/User/Userspace/userspace.asm and the SCE (System Call Extension) code can be found at src/Syscall/sce.asm. The entry point is in src/kernel.c

The code I use in kernel.c to jump to Userspace.

...
#include "User/Userspace/userspace.h"

uint64_t user_stack[1024];

void user_main() {
    while (TRUE);
}

void kernel_main(boot_t* __bootinfo) {
    // init code (Up to line 74 in src/kernel.c)
    kernel_userspace_enter(user_main, &user_stack[500]);
}

Nth Edit: I used log cpu_reset in QEMU to get some info when the system crashes:

CPU Reset (CPU 0)
RAX=0000000000006297 RBX=000000000ff1c2b0 RCX=0000000000002d60 RDX=00000000ff000000
RSI=0000000000009ff8 RDI=0000000000002d60 RBP=0000000000000000 RSP=0000000000009ff8
R8 =0000000000000000 R9 =000000000000a1f0 R10=cccccccccccccccd R11=0000000000000202
R12=000000000ff1c176 R13=000000000ff1c177 R14=0000000000006296 R15=0000000000000000
RIP=0000000000002d60 RFL=00000202 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =0010 0000000000000000 00000fff 00a09300 DPL=0 DS   [-WA]
CS =002b 0000000000000000 ffffffff 00a0fb00 DPL=3 CS64 [-RA]
SS =0023 0000000000000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
DS =0010 0000000000000000 00000fff 00a09300 DPL=0 DS   [-WA]
FS =0010 0000000000000000 00000fff 00a09300 DPL=0 DS   [-WA]
GS =0010 0000000000000000 00000fff 00a09300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0030 000000000000a000 00068fff 00a08900 DPL=0 TSS64-avl
GDT=     0000000000005000 00000fff
IDT=     000000000021f000 00000fff
CR0=80010033 CR2=fffffffffffffff8 CR3=0000000000100000 CR4=00000668
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=0000000000000000 CCD=000000000ff1c150 CCO=EFLAGS
EFER=0000000000000d01
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=ff000000ff000000 ff000000ff000000 XMM01=0000000000000000 3ff0000000000000
XMM02=0000000000000000 0000000000000000 XMM03=0015001600400003 0038004000000000
XMM04=0000000000000000 0000000000000000 XMM05=0000000000000000 0000000000000000
XMM06=0000000000000000 0000000000000000 XMM07=0000000000000000 0000000000000000
XMM08=0000000000000000 0000000000000000 XMM09=0000000000000000 0000000000000000
XMM10=0000000000000000 0000000000000000 XMM11=0000000000000000 0000000000000000
XMM12=0000000000000000 0000000000000000 XMM13=0000000000000000 0000000000000000
XMM14=0000000000000000 0000000000000000 XMM15=0000000000000000 0000000000000000

Answer 1

I solved it. At letast I think so....

Remember to get the size of the GDT instance, not the GDT Type when setting up your GDT. If I find something else, I will update this answer.