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

[Luca]

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
> you!

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:
> https://mail.gnu.org/archive/html/bug-hurd/2023-03/msg00085.html
>
> 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
> data).

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.


Luca