[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

From: Luca
Subject: Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port
Date: Tue, 21 Mar 2023 15:19:07 +0100

Il 21/03/23 14:03, Sergey Bugaev ha scritto:
Ah, so you're saying the com port works, but VGA console (or whatever
it's called, I don't have a clue about hardware as you might have
noticed...) support is buggy? That makes sense, I will try com0, thank

I suppose, yes, it might also be x86_64 specific as I tested my changes mostly using the com port.

The gnumach patch adding the API is this one:

Every thread needs to have its own values of fs_base / gs_base, and
you need to store/restore them on context switch by accessing the
appropriate MSR. There's also the swapgs instruction that I'm told is
useful if you also use gs for kernel's own needs (such as per-CPU

I see there are also the rdfsbase/wrfsbase/rdgsbase/wrfgsbase instructions which would simplify a lot this part, but they are relatively new (~10 years)... I guess we need to handle also the case using MSRs/swapgs, which seems quite complicated if made efficient, as it requires to keep track of the GS state on each trap entry. I'll try to have a simple implementation that works, and eventually optimize it later.

Also, as far as I understand, currently per-cpu data are stored in arrays indexed with the cpu number, so maybe we can't take advantage of swapgs anyway.

 From that point on, stderr goes to the Mach console. But glibc cannot
do that on its own (it's up to the user program to declare it has a
command-line arg specifying the device master port name...), so that
won't happen before we get to main ().

I don't know if taking the args from the stack is done only for bootstrap modules, but maybe it could be a trigger to open the console early, at least for the time being.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]