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

2023-03-21 Thread Luca
Il 21/03/23 15:38, Sergey Bugaev ha scritto: But how does a core know its CPU number? Currently through the APIC_ID register, see the CPU_NUMBER macro in i386/i386/cpu_number.h. This would've been easier if we could pass the port name as an env variable, then we could pick some predefined n

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

2023-03-21 Thread Sergey Bugaev
On Tue, Mar 21, 2023 at 6:33 PM Almudena Garcia wrote: > > But how does a core know its CPU number? > > Calling cpu_number() function, or getting its APIC ID from its Local APIC Ah. That's too hardware-y for me to understand; but I see that cpu_number () in i386/i386/cpu_number.c also uses apic,

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

2023-03-21 Thread Sergey Bugaev
On Tue, Mar 21, 2023 at 5:19 PM Luca wrote: > > 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 kern

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

2023-03-21 Thread Sergey Bugaev
On Tue, Mar 21, 2023 at 5:19 PM Luca wrote: > > 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 kern

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

2023-03-21 Thread 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_6

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

2023-03-21 Thread Sergey Bugaev
On Tue, Mar 21, 2023 at 3:52 PM Luca wrote: > > Il 21/03/23 13:37, Sergey Bugaev ha scritto: > > On Tue, Mar 21, 2023 at 3:20 PM Luca wrote: > >> did you add $(task-resume) in the boot script? > > > > $(prompt-task-resume), yes. > > > > But (see my later mail) Mach hits a page fault trying to pri

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

2023-03-21 Thread Luca
Il 21/03/23 13:37, Sergey Bugaev ha scritto: On Tue, Mar 21, 2023 at 3:20 PM Luca wrote: did you add $(task-resume) in the boot script? $(prompt-task-resume), yes. But (see my later mail) Mach hits a page fault trying to printf "task loaded:", it never gets to resuming the task. This must be

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

2023-03-21 Thread Sergey Bugaev
On Tue, Mar 21, 2023 at 3:20 PM Luca wrote: > did you add $(task-resume) in the boot script? $(prompt-task-resume), yes. But (see my later mail) Mach hits a page fault trying to printf "task loaded:", it never gets to resuming the task. This must be due to some difference in how we're running QE

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

2023-03-21 Thread Luca
Il 21/03/23 11:28, Sergey Bugaev ha scritto: On Tue, Mar 21, 2023 at 12:48 PM Luca wrote: Great! if you still have issues with the long mode, you could try to hack gnumach to wait at some point (e.g. user_bootstrap() or setup_main()), attach with gdb and then continue. Either with some delay or

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

2023-03-21 Thread Sergey Bugaev
On Tue, Mar 21, 2023 at 2:04 PM Sergey Bugaev wrote: > It seems to parse the bootscript correctly. It starts the initial > thread, which loads the ELF and then hangs right here (on printf???): > > > > Does that ring any bells? Maybe this will shed some light: (gdb) s charput (pos=3840, ch=116 '

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

2023-03-21 Thread Sergey Bugaev
On Tue, Mar 21, 2023 at 1:28 PM Sergey Bugaev wrote: > > On Tue, Mar 21, 2023 at 12:48 PM Luca wrote: > > Great! if you still have issues with the long mode, you could try to > > hack gnumach to wait at some point (e.g. user_bootstrap() or > > setup_main()), attach with gdb and then continue. Eit

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

2023-03-21 Thread Luca
Il 21/03/23 10:11, Sergey Bugaev ha scritto: Can you attach with gdb at this point? IIRC you can also dynamically enable/disable the gdb server through the qemu monitor, or stop and see the registers from there. Sure: (gdb) target rem :1234 Remote debugging using :1234 warning: Remote gdbserve

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

2023-03-21 Thread Sergey Bugaev
On Tue, Mar 21, 2023 at 11:36 AM Luca wrote: > > Il 20/03/23 20:10, Sergey Bugaev ha scritto: > > I've gone through the process again (without GDB, even, for now). > > Attaching two screenshots: the first one shows what I input to GRUB > > (seemingly all correct?), on the second one Mach boots, pr

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

2023-03-21 Thread Luca
Il 20/03/23 20:10, Sergey Bugaev ha scritto: I've gone through the process again (without GDB, even, for now). Attaching two screenshots: the first one shows what I input to GRUB (seemingly all correct?), on the second one Mach boots, prints "1 bootstrap modules" and... just sits there doing noth

Re: [PATCH gnumach] Align the user stack correctly for 64 bit programs.

2023-03-21 Thread Luca
Il 21/03/23 04:58, Flávio Cruz ha scritto: Il 20/03/23 05:59, Flavio Cruz ha scritto: > diff --git a/i386/i386/thread.h b/i386/i386/thread.h > index cb317bee..c5da7522 100644 > --- a/i386/i386/thread.h > +++ b/i386/i386/thread.h > @@ -225,6 +225,17 @@ typedef struct p