why booting APs needs an indirect call in the mit6.828 example OS kernel?

Question

I'm studying mit6.828 course, I don't understand why it must indirect call when booting APs in lab4. I try to direct call call mp_main(source code: movl $mp_main, %eax; call *%eax), but it causes triple fault. Here is part of the source code

###################################################################
# entry point for APs
###################################################################

# Each non-boot CPU ("AP") is started up in response to a STARTUP
# IPI from the boot CPU.  Section B.4.2 of the Multi-Processor
# Specification says that the AP will start in real mode with CS:IP
# set to XY00:0000, where XY is an 8-bit value sent with the
# STARTUP. Thus this code must start at a 4096-byte boundary.
#
# Because this code sets DS to zero, it must run from an address in
# the low 2^16 bytes of physical memory.
#
# boot_aps() (in init.c) copies this code to MPENTRY_PADDR (which
# satisfies the above restrictions).  Then, for each AP, it stores the
# address of the pre-allocated per-core stack in mpentry_kstack, sends
# the STARTUP IPI, and waits for this code to acknowledge that it has
# started (which happens in mp_main in init.c).
#
# This code is similar to boot/boot.S except that
#    - it does not need to enable A20
#    - it uses MPBOOTPHYS to calculate absolute addresses of its
#      symbols, rather than relying on the linker to fill them


    # Switch to the per-cpu stack allocated in boot_aps()
    movl    mpentry_kstack, %esp
    movl    $0x0, %ebp       # nuke frame pointer

    # Call mp_main().  (Exercise for the reader: why the indirect call?)
    movl    $mp_main, %eax
    call    *%eax

I don't konw how to debug with gdb in multi-cpu especially at boot, but the entry.S is similar to this code and it's easy to debug. Here is entry.S key code

    mov $relocated, %eax
    jmp *%eax   
relocated:
    movl    $0x0,%ebp           # nuke frame pointer

Below is the gdb output of the correct code. Before jmp *%eax, eip is low address, but after it eip is high address. And the next instruction is mov $0, %ebp.

(gdb) si
=> 0x10002d:    jmp    *%eax
0x0010002d in ?? ()
(gdb) info reg eax eip
eax            0xf010002f   -267386833
eip            0x10002d 0x10002d
(gdb) si
=> 0xf010002f:  mov    $0x0,%ebp
0xf010002f in ?? ()
(gdb) info reg eax eip
eax            0xf010002f   -267386833
eip            0xf010002f   0xf010002f

If we change to direct call relocated instead of mov $relocated, %eax; jmp *%eax, it causes a triple fault, and gdb output:

(gdb) 
=> 0x100028:    call   0x10002d
0x00100028 in ?? ()
(gdb) info reg eip 
eip            0x100028 0x100028
(gdb) si
=> 0x100028:    call   0x10002d
0x00100028 in ?? ()

If we look at objdump output

    call relocated
f0100028:   e8 00 00 00 00          call   f010002d <relocated>

f010002d <relocated>:
relocated:

    # Clear the frame pointer register (EBP)
    # so that once we get into debugging C code,
    # stack backtraces will be terminated properly.
    movl    $0x0,%ebp           # nuke frame pointer
f010002d:   bd 00 00 00 00          mov    $0x0,%ebp

Here both virtual address [0xf0000000, 0xf0000000+4MB) and [0, 4MB) are mapped to physical address [0, 4MB)

I want to know how indirect call changes this. the full code you can find in github just search 'mit6.828' in kern/entry.S and kern/mpentry.S