1. 23 Jun, 2022 2 commits
  2. 01 Sep, 2020 2 commits
  3. 06 Mar, 2019 2 commits
  4. 19 Aug, 2018 2 commits
    • jhb's avatar
      Fix the MPTable probe code after the 4:4 changes on i386. · 4f91615a
      jhb authored
      The MPTable probe code was using PMAP_MAP_LOW as the PA -> VA offset
      when searching for the table signature but still using KERNBASE once
      it had found the table.  As a result, the mpfps table pointed into a
      random part of the kernel text instead of the actual MP Table.
      
      Rather than adding more #ifdef's, use BIOS_PADDRTOVADDR from
      <machine/pc/bios.h> which already uses PMAP_MAP_LOW on i386 and KERNBASE
      on amd64.
      
      Reviewed by:	kib
      MFC after:	1 week
      Differential Revision:	https://reviews.freebsd.org/D16802
      4f91615a
    • John Baldwin's avatar
      Fix the MPTable probe code after the 4:4 changes on i386. · 38a13e90
      John Baldwin authored
      The MPTable probe code was using PMAP_MAP_LOW as the PA -> VA offset
      when searching for the table signature but still using KERNBASE once
      it had found the table.  As a result, the mpfps table pointed into a
      random part of the kernel text instead of the actual MP Table.
      
      Rather than adding more #ifdef's, use BIOS_PADDRTOVADDR from
      <machine/pc/bios.h> which already uses PMAP_MAP_LOW on i386 and KERNBASE
      on amd64.
      
      Reviewed by:	kib
      MFC after:	1 week
      Differential Revision:	https://reviews.freebsd.org/D16802
      38a13e90
  5. 13 Jul, 2018 2 commits
  6. 13 Apr, 2018 2 commits
    • 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
    • Konstantin Belousov's avatar
      i386 4/4G split. · d86c1f0d
      Konstantin Belousov 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
      d86c1f0d
  7. 27 Nov, 2017 2 commits
    • pfg's avatar
      sys/x86: further adoption of SPDX licensing ID tags. · 921a5b48
      pfg authored
      Mainly focus on files that use BSD 2-Clause license, however the tool I
      was using misidentified many licenses so this was mostly a manual - error
      prone - task.
      
      The Software Package Data Exchange (SPDX) group provides a specification
      to make it easier for automated tools to detect and summarize well known
      opensource licenses. We are gradually adopting the specification, noting
      that the tags are considered only advisory and do not, in any way,
      superceed or replace the license texts.
      921a5b48
    • Pedro F. Giffuni's avatar
      sys/x86: further adoption of SPDX licensing ID tags. · ebf5747b
      Pedro F. Giffuni authored
      Mainly focus on files that use BSD 2-Clause license, however the tool I
      was using misidentified many licenses so this was mostly a manual - error
      prone - task.
      
      The Software Package Data Exchange (SPDX) group provides a specification
      to make it easier for automated tools to detect and summarize well known
      opensource licenses. We are gradually adopting the specification, noting
      that the tags are considered only advisory and do not, in any way,
      superceed or replace the license texts.
      ebf5747b
  8. 10 Aug, 2017 6 commits
    • royger's avatar
      mptable: fix i386 build failure · 89ad37fb
      royger authored
      Reported by:	emaste
      X-MFC-with:	r322347
      89ad37fb
    • Roger Pau Monné's avatar
      mptable: fix i386 build failure · 3f0a9fe0
      Roger Pau Monné authored
      Reported by:	emaste
      X-MFC-with:	r322347
      3f0a9fe0
    • royger's avatar
      x86: bump MAX_APIC_ID to 512 · 55936e52
      royger authored
      Introduce a new define to take int account the xAPIC ID limit, for
      systems where x2APIC is not available/reliable.
      
      Also change some of the usages of the APIC ID to use an unsigned int
      (which is the correct storage type to deal with x2APIC IDs as found in
      x2APIC MADT entries).
      
      This allows booting FreeBSD on a box with 256 CPUs and APIC IDs up to
      295:
      
      FreeBSD/SMP: Multiprocessor System Detected: 256 CPUs
      FreeBSD/SMP: 1 package(s) x 64 core(s) x 4 hardware threads
      Package HW ID = 0
      	Core HW ID = 0
      		CPU0 (BSP): APIC ID: 0
      		CPU1 (AP/HT): APIC ID: 1
      		CPU2 (AP/HT): APIC ID: 2
      		CPU3 (AP/HT): APIC ID: 3
      [...]
      	Core HW ID = 73
      		CPU252 (AP): APIC ID: 292
      		CPU253 (AP/HT): APIC ID: 293
      		CPU254 (AP/HT): APIC ID: 294
      		CPU255 (AP/HT): APIC ID: 295
      
      Submitted by:		kib (previous version)
      Relnotes:		yes
      MFC after:		1 month
      Reviewed by:		kib
      Differential revision:	https://reviews.freebsd.org/D11913
      55936e52
    • Roger Pau Monné's avatar
      x86: bump MAX_APIC_ID to 512 · a74bb29a
      Roger Pau Monné authored
      Introduce a new define to take int account the xAPIC ID limit, for
      systems where x2APIC is not available/reliable.
      
      Also change some of the usages of the APIC ID to use an unsigned int
      (which is the correct storage type to deal with x2APIC IDs as found in
      x2APIC MADT entries).
      
      This allows booting FreeBSD on a box with 256 CPUs and APIC IDs up to
      295:
      
      FreeBSD/SMP: Multiprocessor System Detected: 256 CPUs
      FreeBSD/SMP: 1 package(s) x 64 core(s) x 4 hardware threads
      Package HW ID = 0
      	Core HW ID = 0
      		CPU0 (BSP): APIC ID: 0
      		CPU1 (AP/HT): APIC ID: 1
      		CPU2 (AP/HT): APIC ID: 2
      		CPU3 (AP/HT): APIC ID: 3
      [...]
      	Core HW ID = 73
      		CPU252 (AP): APIC ID: 292
      		CPU253 (AP/HT): APIC ID: 293
      		CPU254 (AP/HT): APIC ID: 294
      		CPU255 (AP/HT): APIC ID: 295
      
      Submitted by:		kib (previous version)
      Relnotes:		yes
      MFC after:		1 month
      Reviewed by:		kib
      Differential revision:	https://reviews.freebsd.org/D11913
      a74bb29a
    • royger's avatar
      apic_enumerator: only set mp_ncpus and mp_maxid at probe cpus phase · 345fb326
      royger authored
      Populate the lapics arrays and call cpu_add/lapic_create in the setup
      phase instead. Also store the max APIC ID found in the newly
      introduced max_apic_id global variable.
      
      This is a requirement in order to make the static arrays currently
      using MAX_LAPIC_ID dynamic.
      
      Sponsored by:		Citrix Systems R&D
      MFC after:		1 month
      Reviewed by:		kib
      Differential revision:	https://reviews.freebsd.org/D11911
      345fb326
    • Roger Pau Monné's avatar
      apic_enumerator: only set mp_ncpus and mp_maxid at probe cpus phase · fd1f83fb
      Roger Pau Monné authored
      Populate the lapics arrays and call cpu_add/lapic_create in the setup
      phase instead. Also store the max APIC ID found in the newly
      introduced max_apic_id global variable.
      
      This is a requirement in order to make the static arrays currently
      using MAX_LAPIC_ID dynamic.
      
      Sponsored by:		Citrix Systems R&D
      MFC after:		1 month
      Reviewed by:		kib
      Differential revision:	https://reviews.freebsd.org/D11911
      fd1f83fb
  9. 28 Jan, 2017 2 commits
  10. 15 Jan, 2017 2 commits
  11. 27 May, 2016 1 commit
  12. 21 Feb, 2014 1 commit
  13. 27 Dec, 2013 1 commit
  14. 11 Dec, 2013 2 commits
  15. 09 Dec, 2013 2 commits
  16. 16 Jul, 2011 2 commits
  17. 15 Jul, 2011 2 commits
    • John Baldwin's avatar
      Respect the BIOS/firmware's notion of acceptable address ranges for PCI · 34ff71ee
      John Baldwin authored
      resource allocation on x86 platforms:
      - Add a new helper API that Host-PCI bridge drivers can use to restrict
        resource allocation requests to a set of address ranges for different
        resource types.
      - For the ACPI Host-PCI bridge driver, use Producer address range resources
        in _CRS to enumerate valid address ranges for a given Host-PCI bridge.
        This can be disabled by including "hostres" in the debug.acpi.disabled
        tunable.
      - For the MPTable Host-PCI bridge driver, use entries in the extended
        MPTable to determine the valid address ranges for a given Host-PCI
        bridge.  This required adding code to parse extended table entries.
      
      Similar to the new PCI-PCI bridge driver, these changes are only enabled
      if the NEW_PCIB kernel option is enabled (which is enabled by default on
      amd64 and i386).
      
      Approved by:	re (kib)
      34ff71ee
    • jhb's avatar
      Respect the BIOS/firmware's notion of acceptable address ranges for PCI · b75d5a0e
      jhb authored
      resource allocation on x86 platforms:
      - Add a new helper API that Host-PCI bridge drivers can use to restrict
        resource allocation requests to a set of address ranges for different
        resource types.
      - For the ACPI Host-PCI bridge driver, use Producer address range resources
        in _CRS to enumerate valid address ranges for a given Host-PCI bridge.
        This can be disabled by including "hostres" in the debug.acpi.disabled
        tunable.
      - For the MPTable Host-PCI bridge driver, use entries in the extended
        MPTable to determine the valid address ranges for a given Host-PCI
        bridge.  This required adding code to parse extended table entries.
      
      Similar to the new PCI-PCI bridge driver, these changes are only enabled
      if the NEW_PCIB kernel option is enabled (which is enabled by default on
      amd64 and i386).
      
      Approved by:	re (kib)
      b75d5a0e
  18. 09 Nov, 2010 2 commits
  19. 08 Nov, 2010 2 commits
    • jhb's avatar
      Sync the APIC startup sequence with amd64: · bfc0fcbf
      jhb authored
      - Register APIC enumerators at SI_SUB_TUNABLES - 1 instead of SI_SUB_CPU - 1.
      - Probe CPUs at SI_SUB_TUNABLES - 1.  This allows i386 to set a truly
        accurate mp_maxid value rather than always setting it to MAXCPU - 1.
      bfc0fcbf
    • John Baldwin's avatar
      Sync the APIC startup sequence with amd64: · c5b0b5fc
      John Baldwin authored
      - Register APIC enumerators at SI_SUB_TUNABLES - 1 instead of SI_SUB_CPU - 1.
      - Probe CPUs at SI_SUB_TUNABLES - 1.  This allows i386 to set a truly
        accurate mp_maxid value rather than always setting it to MAXCPU - 1.
      c5b0b5fc
  20. 01 Nov, 2010 1 commit