• kib's avatar
    i386 4/4G split. · e3089a03
    kib authored
    The change makes the user and kernel address spaces on i386
    independent, giving each almost the full 4G of usable virtual addresses
    except for one PDE at top used for trampoline and per-CPU trampoline
    stacks, and system structures that must be always mapped, namely IDT,
    GDT, common TSS and LDT, and process-private TSS and LDT if allocated.
    
    By using 1:1 mapping for the kernel text and data, it appeared
    possible to eliminate assembler part of the locore.S which bootstraps
    initial page table and KPTmap.  The code is rewritten in C and moved
    into the pmap_cold(). The comment in vmparam.h explains the KVA
    layout.
    
    There is no PCID mechanism available in protected mode, so each
    kernel/user switch forth and back completely flushes the TLB, except
    for the trampoline PTD region. The TLB invalidations for userspace
    becomes trivial, because IPI handlers switch page tables. On the other
    hand, context switches no longer need to reload %cr3.
    
    copyout(9) was rewritten to use vm_fault_quick_hold().  An issue for
    new copyout(9) is compatibility with wiring user buffers around sysctl
    handlers. This explains two kind of locks for copyout ptes and
    accounting of the vslock() calls.  The vm_fault_quick_hold() AKA slow
    path, is only tried after the 'fast path' failed, which temporary
    changes mapping to the userspace and copies the data to/from small
    per-cpu buffer in the trampoline.  If a page fault occurs during the
    copy, it is short-circuit by exception.s to not even reach C code.
    
    The change was motivated by the need to implement the Meltdown
    mitigation, but instead of KPTI the full split is done.  The i386
    architecture already shows the sizing problems, in particular, it is
    impossible to link clang and lld with debugging.  I expect that the
    issues due to the virtual address space limits would only exaggerate
    and the split gives more liveness to the platform.
    
    Tested by: pho
    Discussed with:	bde
    Sponsored by:	The FreeBSD Foundation
    MFC after:	1 month
    Differential revision:	https://reviews.freebsd.org/D14633
    e3089a03