IRC channel logs

<damo22>USER_DS gets set to SS not DS

<damo22>maybe that is it

<damo22> * Code and stack selectors have already been

<damo22> * checked. Others will be reset by 'iret'

<damo22> * if they are not valid.

<damo22>does iret reset gs to 0?

<youpi>no, it just sets cs:ip

<youpi>and flags

<azert>damo22:

<azert>what about context switching, how do you deal with that?

<youpi>it's in switch_ktss

<youpi>we update the gs base

<damo22>#if defined(__x86_64__) && !defined(USER32)

<damo22> wrmsr(MSR_REG_FSBASE, pcb->ims.sbs.fsbase);

<damo22> wrmsr(MSR_REG_KGSBASE, pcb->ims.sbs.gsbase);

<damo22>#endif

<damo22>maybe i dont need to push %gs and pop %gs with PUSH_SEGMENTS and POP_SEGMENTS?

<youpi>I wonder if that's really needed indeed

<sobkas>Ok had to switch to vesa as qxl had some horrible memory leaks

<damo22>RIP ffffffff8103df4d EFLAGS 00010006

<damo22>trapno 14: Page fault, error 00000002

<damo22>panic {cpu0} ../i386/i386/trap.c:230: kernel_trap: kernel thread accessed user s

<damo22>pace!

<damo22>0xffffffff8103df4d <all_intrs+65>: 0x00d504ff

<damo22>it crashed in bootstrap_create

<damo22>heh it trapped in printf

<azert>damo22: I suspect popping gs sets gsbase to zero

<damo22>yea i fixed that

<damo22>>>>>> Page fault (14) for W fffffffe61796000 at all_intrs+0x41 <<<<<

<damo22>all_intrs(...)+0x41

<damo22>charmvup(...)+0x1e

<damo22>kd_putc(...)+0x7a

<damo22>kdcnputc(...)+0xad

<damo22>cnputc.part.0(...)+0x28

<damo22>cnputc(...)+0x1d

<damo22>_doprnt(...)+0x329

<damo22>printf(...)+0x4b

<damo22>bootstrap_create(...)+0x2b0

<damo22>start_kernel_threads(...)+0x17b

<damo22>thread_continue(...)+0x39

<damo22>switch_to_shutdown_context()

<damo22>305 err = boot_script_parse_line (&bmods[i], line);

<damo22>303 char *line = (char*)phystokv(bmods[i].string); ??

<damo22>do we need phystokv there?

<youpi>yes, the multiboot information is using physical addresses

<damo22>0xffffffff81087a47 206 losers = boot_script_set_variable

<damo22>1: x/i $pc

<damo22>=> 0xffffffff81087a47 <bootstrap_create+215>: call 0xffffffff8108c9b0 <boot_script_set_variable>

<damo22>is that supposed to be a function call?

<youpi>it's a function and call is the instruction to make a function call, yes

<damo22>oops yes its multiline

<damo22>it traps there

<youpi>bogus rsp ?

<damo22>it seems to change behaviour on every run

<damo22>result is a page fault >>>>> Page fault (14) for W fffffffe61796000 at all_intrs+0x41 <<<<<

<damo22>must be interrupt related

<damo22>ISR 48 is set

<damo22>(Clock interrupt)

<damo22>i think i know what i did

<sobkas>For now I use stubs for libdrm and filling them https://paste.debian.net/hidden/4b1c0843

<damo22>i think i removed a CPU_NUMBER() in all_intrs by mistake

<damo22>ok now i fixed that, i have :

<damo22>start pci-arbiter: HANG and GS = 0 with base address 0

<damo22>CR2=00000000000004a0

<damo22>stopped in trap_from_kernel

<damo22>%ss is always set to KERNEL_DS ?

<youpi>iirc yes

<youpi>because we set it in the master TSS

<youpi>so the processor does the switch

<damo22>ok i am a bit confused, if userspace sets %gs register to 0, it will wipe the gs base, so how do we stop that from killing the kernel?

<youpi>it wipes the user gs base

<youpi>not the kernel gs base

<damo22>well, it wipes the current value of the gsbase

<youpi>which is the user gs base while in user land

<damo22>ok so a kernel thread cannot run while userspace is also running?

<youpi>processors run only one thing at a time

<damo22>ah yes

<damo22>somehow FS is zero when DS is 0x10

<youpi>that's not really surprising: the kernel doesn't use fs atm

<damo22>i think the problem is, a kernel thread is running "in userspace"

<damo22>because the first thread is launched as a userspace thread

<damo22>so there is no need to swapgs during early bringup when the first thread is running

<damo22>start pci-arbiter: Kernel Page fault trap, eip 0xffffffff8103e7fa, code 0, cr2 c

<damo22>kernel: Page fault (14), code=0

<damo22>Stopped at splsched+0x6: TODO

<damo22>splsched(...)+0x6

<damo22>_Xthread_set_state(...)+0xa5

<damo22>ipc_kobject_server(...)+0xac

<damo22>mach_msg_trap(...)+0x7b3

<damo22>syscall64(...)+0x108

<damo22>>>>>> user space <<<<<

<damo22>thats looking better than before

<damo22>this is the furthest ive got so far https://git.zammit.org/gnumach-sv.git/log/?h=smp64-upstream

<damo22>it still throws the above page fault

<damo22>looks like while inside a 64b syscall, it calls _Xthread_set_state

<damo22>so while in a user context, it tries to call splsched() which breaks

<damo22>do i swapgs at the start of every syscall64 and at the end?

<damo22>maybe i need to swap it 4 times

<damo22>do i need to wrap syscall64_call in swapgs?

<etno>sobkas: Since we don't have any DRM driver, wouldn't it be desirable that mesa builds without the need for stubs ?

<etno>AIUI, this is the common code for mesa drivers using DRM. Removing that part from the build may be a possibility ?

<damo22>we would need to add it all back again when we write drm

<etno>Yes, but mesa should be able to build for a system without any DRM support and still do sw-rendering

<etno>And I think that it may actually be possible by disabling DRI support

<etno>(on the other hand, I failed so far to do so; so probably talking too loud 😅)

<etno>My idea was : gallium(softpipe or llvm) + DRI disabled + GLX(direct-glx)

<damo22>i see

<damo22>GS =0000 ffffffff810bb000 00000000 00201300

<damo22>now the base address is correct but the selector is 0

<damo22>i think that invalidates the segment

<youpi>damo22: syscall64 is a clear user-to-kernel entry, so swapgs is required, yes

<azert>damo22: in long mode, gs can be zero, it shouldn't invalidate the base

<youpi>azert: loading 0 into gs does invalidate the base

<youpi> https://pastebin.aquilenet.fr/?a840294d5142c323#7AePWpo1QkxP2WjuJRew5sFktrJizofuRQ12xUSUwoPc

<damo22>youpi: so i think the issue is the selector is 0 and wipes gs, but even after i restore the base address the selector remains 0 and still doesnt allow it to resolve gs:addresses

<azert>youpi: that's because you load 0 into gs, indeed

<azert>but if you restore the gsbase using wrgsbase, then the fact that it is zero doesn't matter in long mode

<youpi>see right above damo22 saying "even after i restore the base address the selector remains 0 and still doesnt allow it to resolve gs:addresses"

<damo22>let me try loading the selector as well as the base

<youpi>damo22: I don't see linux restoring gs, it just leaves it as it was in user land

<youpi>i.e. user land can change gs (and thus clear the gs base), the kernel doesn't care, and just uses swapgs to restore the gs base without caring about gs itself

<azert>I found this at page 168 of the manual: the processor does not perform runtime checking on NULL segment selectors

<azert>in 64-bit mode

<azert>so that's not the issue

<damo22>well the selector brings in the access/flags bits?

<azert>that's for cs and ds

<damo22>when its broken i get :

<damo22>GS =0000 ffffffff810bb000 00000000 00201300

<azert>if the base is correct then it doesn't break because of fs

<azert>s/fs/gs/

<damo22>the 00201300 might be wrong

<azert>could be that

<damo22>i think it should be 00209300

<damo22>which is loaded when i set the gs selector to the 0x68

<azert>I would leave the gs selector to zero

<azert>it's just a compatibility feature

<damo22>ok

<azert>really they could have just substitute gs with a couple of registers, instead they decided to keep it for compatibility with i386

<damo22>ok so i am in gdb breakpointed at syscall64

<damo22>GS =0000 ffffffff810bb000 00000000 00000000

<azert>that's different

<damo22>after the swapgs it did not change

<damo22>so both msrs have the same value

<azert>you need to set them in the kernel, they don't change in the userspace

<azert>and I would avoid using selectors to change them

<azert>first of all, because they just modify the lower 32 bit

<damo22>right

<youpi>damo22: I guess we can drop a part of your Add GS segment configuration to early gdt commit: we want the gs base part, but we don't need the boot GS part and loading $PERCPU_DS

<youpi>and probably we don't need to set it up in gdt_fill either

<damo22>okay i wasnt sure

<azert>it might be needed for the USER_32 feature

<youpi>not the PERCPU_DS segment

<azert>I think that USER_32 was a sexy concept like in 2000 when amd64 was made

<azert>because software back then rarely needed more then 4gb each

<youpi>it's not just sexy. It allows now to keep some hurd-i386 packages built

<youpi>because they now require a lot of virtual memory

<azert>after debian will drop the linux i386 distribution, I suppose hurd should do it too

<youpi>sure

<Pellescours>damo22: I see that when you setup the swapgs you set the kernel value in both (gs_base & kgs_base). I hope the user value is cleared before jumping on userland otherwise I fear a security hole (kernel gs in userland so userland being able to hack something and reach kernel memory)

<damo22>i dont know how to protect kernel from that, if someone knows the address

<damo22>if they are able to set gs base

<azert>damo22: of course the userspace cannot set the kernel gsbase

<azert>neither read that

<azert>just leave the userspace gs_base alone, you basically shouldn't care about what is there

<azert>or put an absurd value there; like -1ULL

<azert>that will be useful for debugging swapgs issues

<azert>0xDEADBEEFDEADBEEF

<damo22>kernel: Page fault (14), code=0

<damo22>Stopped at splsched+0x6: TODO

<damo22>splsched(...)+0x6

<damo22>_Xthread_set_state(...)+0xa5

<damo22>ipc_kobject_server(...)+0xac

<damo22>mach_msg_trap(...)+0x7b3

<damo22>syscall64(...)+0x10c

<damo22>>>>>> user space <<<<<

<damo22>CR2 = 0xc

<damo22>GS =0000 ffffffff810bb000 000fffff 00000000

<damo22>i am going to push what ive got and leave it for tonighe

<damo22>s/e/t

<damo22>pushed

<damo22>nn

<sobkas>etno: drm is needed for dri it's not used but still needs it during compilation, it was easier to add stubs than fix dependency on drm

<etno>sobkas: The idea would be to disable dri itself.

<sobkas>etno: without dri it build libgl so I don't liked it

<sobkas>will look at it again

<etno>sobkas: any solution that works will suite me in the end. And as Damo mentioned, a stub drm.h file would be a first step towards an actual implementation.

<sobkas>etno: from meson.build

<sobkas># FIXME: haiku doesn't use dri, and xlib doesn't use dri, probably should

<sobkas>I agree with this sentiment that xlib shouldn't be a special case

<sobkas>as of stubs I have file full of #define _IOT_drm_buf_desc (0) and it compiles and works(need to actually check?)

<gnu_srs1>etno: sobkas: Please look ate the upstream patches, see merge request: https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/443

<gnu_srs1>And comment on what has already been done.

<sobkas>I got comment to not use thatwe shouldn't use ioccom.h

<sobkas>ok I'm trying other option for mesa

<gnu_srs1>I have patches enabling a lot in mesa. The only remaining problem is glxgears works with ssh -Y but not in the window manager. Probably a shared memory issue.

<gnu_srs1>I would appreciate help to find out the cause. Shall I send the patches to the ML?

<sobkas>with some if violence I was able to compile mesa without(not 100% sure) drm

<sobkas>Ok glxgears works with ssh -X/Y and on window manager

<sobkas>gnujump also jums

<sobkas>I still have problems with code=139

<sobkas>And I'm unable to make qxl work with opengl

IRC channel logs

2026-01-11.log