This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Mach".

The branch, master has been updated
       via  3ec9cdbf9a18a126b6d8f0bf4da2702823e0a198 (commit)
      from  36e4236b1636e10a622745c35d6db210f7f2fdc4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 3ec9cdbf9a18a126b6d8f0bf4da2702823e0a198
Author: David Bidner <[email protected]>
Date:   Wed Oct 7 05:21:39 2026 +0200

    i386/cpuboot: load null IDT from its address, not from physical 0
    
    When an AP starts, apboot32 loads the null IDT with
    
        mov     apboot_idt_ptr, %ebx
        lidt    (%ebx)
    
    The first instruction loads the contents of apboot_idt_ptr, which is zero,
    so lidt then loads the pseudo-descriptor from DS:0.  The AP is running with
    the early per-CPU segment base of -KERNELBASE (0x40000000), so that is
    linear address 0x40000000, i.e. physical address 0x40000000.
    
    That physical address is RAM only when the guest has more than 1 GiB.  On a
    two-CPU i386 PAE machine with 512 or 1024 MiB it is the start of the PCI
    hole, the AP never retires lidt, and the BSP spins forever in the unbounded
    "Waiting for AP 1" loop in mp_desc.c.  With 1280 MiB or more the read lands
    in RAM and the AP happens to continue.
    
    Load the address instead, matching the amd64 path:
    
        movl    $apboot_idt_ptr, %ebx
        lidt    (%ebx)
    
    so that the null pseudo-descriptor (limit 0, base 0) is read from
    apboot_idt_ptr itself.
    
    Tested by booting a two-CPU i386 PAE QEMU/KVM guest at 512, 1024 and
    1536 MiB: before this change the 512 and 1024 MiB guests hang in
    "Waiting for AP 1", after it they reach userland with the AP online.  A
    single-CPU i386 guest and two-CPU amd64 guests at the same sizes are
    unaffected.  Only i386 PAE boot-to-userland was exercised; no long-running
    behaviour was tested.
    Message-ID: <[email protected]>

-----------------------------------------------------------------------

Summary of changes:
 i386/i386/cpuboot.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
GNU Mach

Reply via email to