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
>
