• D
    [SPARC64]: Get SUN4V SMP working. · 72aff53f
    David S. Miller 提交于
    The sibling cpu bringup is extremely fragile.  We can only
    perform the most basic calls until we take over the trap
    table from the firmware/hypervisor on the new cpu.
    
    This means no accesses to %g4, %g5, %g6 since those can't be
    TLB translated without our trap handlers.
    
    In order to achieve this:
    
    1) Change sun4v_init_mondo_queues() so that it can operate in
       several modes.
    
       It can allocate the queues, or install them in the current
       processor, or both.
    
       The boot cpu does both in it's call early on.
    
       Later, the boot cpu allocates the sibling cpu queue, starts
       the sibling cpu, then the sibling cpu loads them in.
    
    2) init_cur_cpu_trap() is changed to take the current_thread_info()
       as an argument instead of reading %g6 directly on the current
       cpu.
    
    3) Create a trampoline stack for the sibling cpus.  We do our basic
       kernel calls using this stack, which is locked into the kernel
       image, then go to our proper thread stack after taking over the
       trap table.
    
    4) While we are in this delicate startup state, we put 0xdeadbeef
       into %g4/%g5/%g6 in order to catch accidental accesses.
    
    5) On the final prom_set_trap_table*() call, we put &init_thread_union
       into %g6.  This is a hack to make prom_world(0) work.  All that
       wants to do is restore the %asi register using
       get_thread_current_ds().
    
    Longer term we should just do the OBP calls to set the trap table by
    hand just like we do for everything else.  This would avoid that silly
    prom_world(0) issue, then we can remove the init_thread_union hack.
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    72aff53f
smp.c 32.0 KB