Re: SMP support

So, I've started taking an attempt at this using Claude Code.

I'm quoting Claude's progress report below.

What's the project's policy regarding AI-generated code?

    agape
    brent

● Here's a summary of the changes needed to enable x86_64 SMP support in
> GNU Mach:
>
>   Changes Required for x86_64 SMP Support
>
>   1. Build System Configuration (COMPLETED)
>
>   - debian/rules: Add AMD64 SMP build configuration alongside existing
> i386 SMP support, including package installation rules
>   - x86_64/Makefrag.am: Add x86_64/x86_64/cpuboot.S to the build sources
>
>   2. AP Boot Code - Early Long Mode Transition (COMPLETED)
>
>   x86_64/x86_64/cpuboot.S: Complete rewrite to transition APs (Application
> Processors) to 64-bit long mode early in the boot process, before accessing
> high kernel memory:
>   - Add 64-bit GDT for long mode transition
>   - Enable PAE (Physical Address Extension)
>   - Load BSP's page tables (p4table) into CR3
>   - Enable Long Mode via EFER MSR
>   - Enable paging to activate long mode
>   - Far jump to 64-bit code segment
>   - Convert all subsequent code to use 64-bit registers and RIP-relative
> addressing
>   - Update per-CPU GDT setup to work with 64-bit addressing
>
>   3. Page Table Export (COMPLETED)
>
>   x86_64/boothdr.S: Export p4table as a global symbol so AP boot code can
> reuse the BSP's page tables
>
>   4. CPU Number Detection Macros (COMPLETED)
>
>   i386/i386/cpu_number.h or x86_64/x86_64/cpu_number.h: Split CPU
> detection macros into separate i386 and x86_64 implementations:
>   - Replace %cs: segment override tricks (which don't work in x86_64 long
> mode) with RIP-relative addressing
>   - Use proper 64-bit register operations and addressing modes
>   - Implement CPU_NUMBER_NO_STACK() and CPU_NUMBER_NO_GS() macros for
> x86_64
>
>   5. Remaining Issue (WORK IN PROGRESS)
>
>   The kernel currently boots successfully in UP (uniprocessor) mode but
> crashes before console initialization when built with SMP support (NCPUS >
> 1), even when running with only one CPU. The crash occurs during early
> initialization in acpi_apic_init() or smp_init(), which execute before
> console initialization in machine_init().
>
>   Suspected areas needing investigation:
>   - ACPI XSDT (64-bit) parsing in i386/i386at/acpi_parse_apic.c
>   - GDT initialization and %gs segment register setup for per-CPU data
> access
>   - Potential alignment or data structure size issues with
> percpu_array[NCPUS]
>   - Pointer arithmetic or type issues in 64-bit ACPI table traversal
>
>   The compilation and linking now succeed completely, and all
> x86_64-specific addressing issues have been resolved.  The remaining work
> is debugging the runtime SMP initialization crash.
>
>

On Wed, Nov 19, 2025 at 10:56 AM Samuel Thibault <[email protected]>
wrote:

> Marius Gripsgard, le mer. 19 nov. 2025 15:44:22 +0000, a ecrit:
> > > On 16 Nov 2025, at 19:13, Samuel Thibault <[email protected]>
> wrote:
> > > Brent W. Baccala, le dim. 16 nov. 2025 12:56:30 -0500, a ecrit:
> > >> Dear Samuel,
> > >>
> > >> On Fri, Nov 14, 2025 at 7:05 PM Samuel Thibault <[1]
> [email protected]>
> > >> wrote:
> > >>
> > >>    Brent W. Baccala, le ven. 14 nov. 2025 13:23:07 -0500, a ecrit:
> > >>> How do you enable SMP support?  I've tried starting kvm with `-smp
> 4` but
> > >>    I
> > >>> don't see more than one core in /proc/cpuinfo.
> > >>
> > >>    You need to use the -smp kernel.
> > >>
> > >>
> > >> So, looking over the package lists for "gnumach", it appears that
> there are
> > >> amd64 images and smp images, but no amd64 smp image.
> > >>
> > >> Does this mean we have 64-bit support and SMP support, but can't do
> both at the
> > >> same time?
> > >
> > > I don't think anybody has given any stab at 64b+SMP so far.
> > I’m interested in this, how different would a SMP impl for 64 bit be
> compared to 32 bit?
>
> The bootup procedure for the non-boot processors is probably different
> from 32bit.
>
> Samuel
>