OSDev.org

Octocontrabass wrote:

DevNoteHQ wrote:But what about the other topic?
Can i do something like this:
Userland:

Code: Select all

namespace System
{
   void* Syscall(uint64_t iCall, void* OtherArguments)
   {
      asm volatile("syscall");
      //return?
   }
}

You can have a function like this, but if you want it to actually work, you need to tell GCC how to pass parameters and accept return values. For example:

Code: Select all

void *Syscall( uint64_t iCall, void *OtherArguments)
{
    void *retval;
    asm volatile( "syscall" : "=a"(retval) : "D"(iCall), "S"(OtherArguments) : "memory" );
    return retval;
}

This assumes your syscall handler returns a value in RAX, expects iCall in RDI, expects OtherArguments in RSI, accesses memory belonging to your program (for example, by dereferencing the OtherArguments pointer), and doesn't modify the values in any registers besides RAX. You can change the constraints and clobbers to fit your kernel's syscall handler.

DevNoteHQ wrote:But what about the other topic?
Can i do something like this:
Userland:

Code: Select all

namespace System
{
   void* Syscall(uint64_t iCall, void* OtherArguments)
   {
      asm volatile("syscall");
      //return?
   }
}

[snip]
Why isn't just calling "Syscall(iCode, OtherArguments);" enough? Shouldn't GCC store "iCode" in RDI and "OtherArguments" in RSI anyway? Or is this again for preventing gcc from optimizing my code away?

Octocontrabass wrote: You can have a function like this, but if you want it to actually work, you need to tell GCC how to pass parameters and accept return values. For example:

Code: Select all

void *Syscall( uint64_t iCall, void *OtherArguments)
{
    void *retval;
    asm volatile( "syscall" : "=a"(retval) : "D"(iCall), "S"(OtherArguments) : "memory" );
    return retval;
}

Korona wrote:MSR_GS_BASE is the GS base address. swapgs swaps MSR_GS_BASE and MSR_KERNEL_GS_BASE. Both registers need to be set up manually.

There is no instruction to access the kernel stack base from the TSS. swapgs is meant to solve exactly that problem. Use swapgs to load a known GS base and then load the kernel RSP from the GS segment.

All this applies only to syscall. Interrupts automatically load RSP from the TSS. Its probably a good idea to swapgs anyway in order to be able to rely on a consistent GS segment for per-CPU data in your kernel.

MichaelPetch wrote:

Octocontrabass wrote: You can have a function like this, but if you want it to actually work, you need to tell GCC how to pass parameters and accept return values. For example:

Code: Select all

void *Syscall( uint64_t iCall, void *OtherArguments)
{
    void *retval;
    asm volatile( "syscall" : "=a"(retval) : "D"(iCall), "S"(OtherArguments) : "memory" );
    return retval;
}

At the very least you are going to want to add R11 and RCX to the clobbers since the SYSCALL instruction itself will overwrite those registers.

void *Syscall( uint64_t iCall, void *OtherArguments)
{
    void *retval;
    asm volatile( "syscall" : "=a"(retval) : "D"(iCall), "S"(OtherArguments) : "memory", "%rcx", "%r11" );
    return retval;
}

DevNoteHQ wrote:Is that right then?

Code: Select all

void *Syscall( uint64_t iCall, void *OtherArguments)
{
    void *retval;
    asm volatile( "syscall" : "=a"(retval) : "D"(iCall), "S"(OtherArguments) : "memory", "%rcx", "%r11" );
    return retval;
}

MichaelPetch wrote:That loos okay, but the assumption as well that your SYSCALL code in the kernel doesn't clobber any other registers besides RAX. If your SYSCALL code preserves all the registers it uses, yes that code looks okay.

DevNoteHQ wrote:

Korona wrote:MSR_GS_BASE is the GS base address. swapgs swaps MSR_GS_BASE and MSR_KERNEL_GS_BASE. Both registers need to be set up manually.

There is no instruction to access the kernel stack base from the TSS. swapgs is meant to solve exactly that problem. Use swapgs to load a known GS base and then load the kernel RSP from the GS segment.

All this applies only to syscall. Interrupts automatically load RSP from the TSS. Its probably a good idea to swapgs anyway in order to be able to rely on a consistent GS segment for per-CPU data in your kernel.

The RSP0 entry is not automatically set in the TSS, right? So i'll have to save it manually each time i want to leave privilege level 0, right?

DevNoteHQ wrote:

DevNoteHQ wrote:The RSP0 entry is not automatically set in the TSS, right? So i'll have to save it manually each time i want to leave privilege level 0, right?

Or would it be better to create a seperate stack for interrupts/syscalls? Because the interrupt/syscall should remove everything from the stack anyway before iret/sysret...

Brendan wrote:Hi,

It depends on how you want to do kernel stacks.

The most common way is to have a kernel stack for each (user) thread. In this case you set the RSP0 field during task switches - e.g. if CPU #5 switches to thread number #6, you put the "address of kernel stack" value for thread number #6 into the RSP0 field of the TSS that CPU #5 is using. During task switches you'd also change RSP to the thread's "current kernel stack top" (which is different to the "address of kernel stack"), and (possibly long after the task switch was done) if/when you return from the kernel back to user-space you switch from the thread's kernel stack to the thread's user stack, and when an IRQ occurs the CPU switches from the thread's user stack to the thread's kernel stack. Unfortunately; for SYSCALL this switching between the thread's user stack and the thread's kernel stack is something you have to take care of yourself (SYSCALL and SYSRET are the only cases where the CPU doesn't take care of stack switching during a privilege level change).

The other alternative (which is less common and doesn't make much sense for monolithic kernels) is "kernel stack per CPU". In this case you set the RSP0 field in the CPU's TSS once during boot and never have to change it again; but task switching ends up being very different (thread's state saved when switching from user to kernel for any reason, and thread's state loaded when switching from kernel back to user for any reason) and there's usually a few other things different (something to manage what kernel does when, because kernel isn't pre-emptable and can't just switch to other task/s running other kernel code whenever it feels like).


Cheers,

Brendan

DevNoteHQ wrote:

Brendan wrote:It depends on how you want to do kernel stacks.

Thanks!
Can you tell me what to do when the stack is full?

DevNoteHQ wrote:Do i just use stack traces to detect if the stack is full and create a new one somewhere?

DevNoteHQ wrote:And are heap and stack for a process/thread usually created by the kernel? Because the kernel reservates some space for the stack itself. And is the heap for the kernel initialized the same way as the stack for the kernel (="resb HEAP_SIZE")? Or do you usually initialize the heap on top of the stack (=on top of the kernel.elf) when the kernel is already running?

DevNoteHQ wrote:And what use could swapgs have? The only usage of the GS register that i saw was to save CPU-specific information (TSS-address, current thread,...) in the kernelmode register. What could i put into the usermode register? Or is the usermode GS usually empty to prevent processes of reading CPU-specific information?