1. 15 Jan, 2022 1 commit
  2. 12 Jan, 2022 1 commit
    • Colin Percival's avatar
      x86: Speed up clock calibration · c2705cea
      Colin Percival authored
      Prior to this commit, the TSC and local APIC frequencies were calibrated
      at boot time by measuring the clocks before and after a one-second sleep.
      This was simple and effective, but had the disadvantage of *requiring a
      one-second sleep*.
      
      Rather than making two clock measurements (before and after sleeping) we
      now perform many measurements; and rather than simply subtracting the
      starting count from the ending count, we calculate a best-fit regression
      between the target clock and the reference clock (for which the current
      best available timecounter is used). While we do this, we keep track
      of an estimate of the uncertainty in the regression slope (aka. the ratio
      of clock speeds), and stop measuring when we believe the uncertainty is
      less than 1 PPM.
      
      In order to avoid the risk of aliasing resulting from the data-gathering
      loop synchronizing with (a multiple of) the frequency of the reference
      clock, we add some additional spinning depending upon the iteration number.
      
      For numerical stability and simplicity of implementation, we make use of
      floating-point arithmetic for the statistical calculations.
      
      On the author's Dell laptop, this reduces the time spent in calibration
      from 2000 ms to 29 ms; on an EC2 c5.xlarge instance, it is reduced from
      2000 ms to 2.5 ms.
      
      Reviewed by:	bde (previous version), kib
      MFC after:	1 month
      Sponsored by:	https://www.patreon.com/cperciva
      Differential Revision:	https://reviews.freebsd.org/D33802
      c2705cea
  3. 28 Dec, 2021 2 commits
  4. 10 Dec, 2021 1 commit
  5. 08 Dec, 2021 1 commit
  6. 06 Dec, 2021 1 commit
    • Mark Johnston's avatar
      x86: Defer LAPIC calibration until after timecounters are available · 62d09b46
      Mark Johnston authored
      This ensures that we have a good reference timecounter for performing
      calibration.
      
      Change lapic_setup to avoid configuring the timer when booting, and move
      calibration and initial configuration to a new lapic routine,
      lapic_calibrate_timer.  This calibration will be initiated from
      cpu_initclocks(), before an eventtimer is selected.
      
      Reviewed by:	kib, jhb
      MFC after:	2 weeks
      Sponsored by:	The FreeBSD Foundation
      Differential Revision:	https://reviews.freebsd.org/D33206
      62d09b46
  7. 05 Dec, 2021 1 commit
  8. 15 Nov, 2021 1 commit
    • Mark Johnston's avatar
      x86: Implement deferred TSC calibration · 22875f88
      Mark Johnston authored
      There is no universal way to find the TSC frequency.  Newer Intel CPUs
      may report it via CPUID leaves 0x15 and 0x16.  Sometimes it can be
      obtained from the PLATFORM_INFO MSR as well, though we never use that.
      On older platforms we derive the frequency using a DELAY(1000000) call,
      which uses the 8254 PIT.  On some newer platforms the 8254 is apparently
      non-functional, leading to bogus calibration results.  On such platforms
      the TSC frequency must be available from CPUID.  It is also possible to
      disable calibration with a tunable, in which case we try to parse the
      brand string if the TSC freq is not available from CPUID.
      
      CPUID 0x15 provides an authoritative TSC frequency value, but even that
      is not always available on new Intel platforms.  CPUID 0x16 provides the
      specified processor base frequency, which is not the same as the TSC
      frequency.  Empirically, it is close enough for early boot, but too far
      off for timekeeping: on a Comet Lake NUC, CPUID 0x16 yields 1600MHz but
      the TSC frequency is rougly 1608MHz, leading to frequent clock stepping
      when NTP is in use.
      
      Thus we have a situation where we cannot calibrate using the PIT and
      cannot obtain a precise frequency from CPUID (or MSRs).  This change
      seeks to address that by using the CPUID 0x16 value during early boot
      and refining the calibration later once ACPI-based timecounters are
      available.  TSC frequency detection is thus split into two phases:
      
      Early phase:
      - On Intel platforms, query CPUID 0x15 and 0x16 and use that value
        initially if available.
      - Otherwise, get an estimate using the PIT, reducing the delay loop to
        100ms from 1s.
      - Continue to register the TSC as the CPU ticks provider early, even
        though the frequency may be off.  Otherwise any code executed during
        boot that uses cpu_ticks() (e.g., context switching) gets tripped up
        when the ticks provider changes.
      
      Later phase:
      - In SI_SUB_CLOCKS, once the timehands are initialized, load the current
        TSC and timecounter (sbinuptime()) values at the beginning and end of
        a 1s interval and use the timecounter frequency (typically from
        kvmclock, HPET or the ACPI PM timer) to estimate the TSC frequency.
      - Update the TSC timecounter, global tsc_freq and CPU ticker with the
        new frequency and finally register the TSC as a timecounter.
      
      Reviewed by:	kib, jhb (previous version)
      Discussed with:	imp, cperciva
      MFC after:	6 weeks
      Sponsored by:	The FreeBSD Foundation
      Differential Revision:	https://reviews.freebsd.org/D32512
      22875f88
  9. 06 Oct, 2021 1 commit
    • Konstantin Belousov's avatar
      apic: initialize lapic_paddr statically · f8d3368b
      Konstantin Belousov authored
      The default value for LAPIC registers page physical address
      is usually right. Having this value available early makes
      pmap_force_invalidate_cache_range(), used on non-self-snoop machines,
      avoid flushing LAPIC range for early calls.
      
      Reviewed by:	alc, markj
      Sponsored by:	The FreeBSD Foundation
      MFC after:	1 week
      Differential revision:	https://reviews.freebsd.org/D32318
      f8d3368b
  10. 11 Aug, 2021 1 commit
    • Mark Johnston's avatar
      amd64: Add MD bits for KMSAN · b0f71f1b
      Mark Johnston authored
      Interrupt and exception handlers must call kmsan_intr_enter() prior to
      calling any C code.  This is because the KMSAN runtime maintains some
      TLS in order to track initialization state of function parameters and
      return values across function calls.  Then, to ensure that this state is
      kept consistent in the face of asynchronous kernel-mode excpeptions, the
      runtime uses a stack of TLS blocks, and kmsan_intr_enter() and
      kmsan_intr_leave() push and pop that stack, respectively.
      
      Use these functions in amd64 interrupt and exception handlers.  Note
      that handlers for user->kernel transitions need not be annotated.
      
      Also ensure that trap frames pushed by the CPU and by handlers are
      marked as initialized before they are used.
      
      Reviewed by:	kib
      Sponsored by:	The FreeBSD Foundation
      Differential Revision:	https://reviews.freebsd.org/D31467
      b0f71f1b
  11. 01 Jun, 2021 1 commit
  12. 31 May, 2021 1 commit
    • Mark Johnston's avatar
      x86: Fix lapic_ipi_alloc() on i386 · 18f55c67
      Mark Johnston authored
      The loop which checks to see if "dynamic" IDT entries are allocated
      needs to compare with the trampoline address of the reserved ISR.
      Otherwise it will never succeed.
      
      Reported by:	Harry Schmalzbauer <freebsd@omnilan.de>
      Tested by:	Harry Schmalzbauer <freebsd@omnilan.de>
      Reviewed by:	kib
      MFC after:	1 week
      Sponsored by:	The FreeBSD Foundation
      Differential Revision:	https://reviews.freebsd.org/D30576
      18f55c67
  13. 17 May, 2021 1 commit
  14. 30 Apr, 2021 1 commit
    • Eric van Gyzen's avatar
      Wait longer for a previous IPI to be sent · 2f32a971
      Eric van Gyzen authored
      When sending an IPI, if a previous IPI is still pending delivery,
      native_lapic_ipi_vectored() waits for the previous IPI to be sent.
      We've seen a few inexplicable panics with the current timeout of 50 ms.
      Increase the timeout to 1 second and make it tunable.
      
      No hardware specification mentions a timeout in this case; I checked
      the Intel SDM, Intel MP spec, and Intel x2APIC spec.  Linux and illumos
      wait forever.  In Linux, see __default_send_IPI_shortcut() in
      arch/x86/kernel/apic/ipi.c.  In illumos, see apic_send_ipi() in
      usr/src/uts/i86pc/io/pcplusmp/apic_common.c.  However, misbehaving hardware
      could hang the system if we wait forever.
      
      Reviewed by:	mav kib
      MFC after:	1 week
      Sponsored by:	Dell EMC Isilon
      Differential Revision: https://reviews.freebsd.org/D29942
      2f32a971
  15. 13 Apr, 2021 1 commit
    • Mark Johnston's avatar
      amd64: Add MD bits for KASAN · f115c061
      Mark Johnston authored
      - Initialize KASAN before executing SYSINITs.
      - Add a GENERIC-KASAN kernel config, akin to GENERIC-KCSAN.
      - Increase the kernel stack size if KASAN is enabled.  Some of the
        ASAN instrumentation increases stack usage and it's enough to
        trigger stack overflows in ZFS.
      - Mark the trapframe as valid in interrupt handlers if it is
        assigned to td_intr_frame.  Otherwise, an interrupt in a function
        which creates a poisoned alloca region can trigger false positives.
      
      MFC after:	2 weeks
      Sponsored by:	The FreeBSD Foundation
      Differential Revision:	https://reviews.freebsd.org/D29455
      f115c061
  16. 12 Sep, 2020 1 commit
    • Jason A. Harmening's avatar
      amd64: prevent KCSan false positives on LAPIC mapping · 3966af52
      Jason A. Harmening authored
      For configurations without x2APIC support (guests, older hardware), the global
      LAPIC MMIO mapping will trigger false-positive KCSan reports as it will appear
      that multiple CPUs are concurrently reading and writing the same address.
      This isn't actually true, as the underlying physical access will be performed
      on the local CPU's APIC. Additionally, because LAPIC access can happen during
      event timer configuration, the resulting KCSan printf can produce a panic due
      to attempted recursion on event timer resources.
      
      Add a __nosanitizethread preprocessor define to prevent the compiler from
      inserting TSan hooks, and apply it to the x86 LAPIC accessors.
      
      PR:		249149
      Reported by:	gbe
      Reviewed by:	andrew, kib
      Tested by:	gbe
      Differential Revision:	https://reviews.freebsd.org/D26354
      3966af52
  17. 01 Sep, 2020 1 commit
  18. 24 Jul, 2020 1 commit
    • Alexander Motin's avatar
      Make lapic_ipi_vectored(APIC_IPI_DEST_SELF) NMI safe. · 23ce4620
      Alexander Motin authored
      Sending IPI to self or all CPUs does not require write into upper part of
      the ICR, prone to races.  Previously the code disabled interrupts, but it
      was not enough for NMIs.  Instead of that when possible write only lower
      part of the register, or use special SELF IPI register in x2APIC mode.
      
      This also removes ICR reads used to preserve reserved bits on write.
      It was there from the beginning, but I failed to find explanation why,
      neither I see Linux doing it.  Specification even tells that ICR content
      may be lost in deep C-states, so if hardware does not bother to preserve
      it, why should we?
      
      MFC after:	2 weeks
      Sponsored by:	iXsystems, Inc.
      23ce4620
  19. 26 Feb, 2020 1 commit
    • Pawel Biernacki's avatar
      Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many) · 7029da5c
      Pawel Biernacki authored
      r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
      still not MPSAFE (or already are but aren’t properly marked).
      Use it in preparation for a general review of all nodes.
      
      This is non-functional change that adds annotations to SYSCTL_NODE and
      SYSCTL_PROC nodes using one of the soon-to-be-required flags.
      
      Mark all obvious cases as MPSAFE.  All entries that haven't been marked
      as MPSAFE before are by default marked as NEEDGIANT
      
      Approved by:	kib (mentor, blanket)
      Commented by:	kib, gallatin, melifaro
      Differential Revision:	https://reviews.freebsd.org/D23718
      7029da5c
  20. 21 Jan, 2020 1 commit
    • Konstantin Belousov's avatar
      Add support for Hygon Dhyana Family 18h processor. · 2ee49fac
      Konstantin Belousov authored
      As a new x86 CPU vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
      is a joint venture between AMD and Haiguang Information Technology Co.,
      Ltd., aims at providing x86 processors for China server market.
      
      The first generation Hygon processor(Dhyana) shares most architecture
      with AMD's family 17h, but with different CPU vendor ID("HygonGenuine")
      and PCI vendor ID(0x1d94) and family series number 18h(Hygon negotiated
      with AMD to confirm that only Hygon use family 18h).
      
      To enable Hygon Dhyana support in FreeBSD, add new definitions
      HYGON_VENDOR_ID("HygonGenuine") and X86_VENDOR_HYGON(0x1d94) to identify
      Hygon Dhyana CPU.
      
      Initialize the CPU features(topology, local APIC ext, MSI, TSC, hwpstate,
      MCA, DEBUG_CTL, etc) for amd64 and i386 mode by sharing the code path of
      AMD family 17h.
      
      The changes have been applied on FreeBSD 13.0-CURRENT and tested
      successfully on Hygon Dhyana processor.
      
      References:
      [1] Linux kernel patches for Hygon Dhyana, merged in 4.20:
      
      https://git.kernel.org/tip/c9661c1e80b609cd038db7c908e061f0535804ef
      
      [2] MSR and CPUID definition:
      
      https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf
      
      Submitted by:	Pu Wen <puwen@hygon.cn>
      MFC after:	1 week
      Differential revision:	https://reviews.freebsd.org/D23163
      2ee49fac
  21. 12 Jan, 2020 1 commit
  22. 18 Oct, 2019 1 commit
  23. 13 Aug, 2019 1 commit
  24. 06 Mar, 2019 1 commit
  25. 13 Sep, 2018 1 commit
    • Roger Pau Monné's avatar
      lapic: skip setting intrcnt if lapic is not present · d7627401
      Roger Pau Monné authored
      Instead of panicking. Legacy PVH mode doesn't provide a lapic, and
      since native_lapic_intrcnt is called unconditionally this would cause
      the assert to trigger. Change the assert into a continue in order to
      take into account the possibility of systems without a lapic.
      
      Reviewed by:		jhb
      Approved by:		re (gjb)
      Sponsored by:		Citrix Systems R&D
      Differential revision:	https://reviews.freebsd.org/D17015
      d7627401
  26. 28 Aug, 2018 1 commit
    • John Baldwin's avatar
      Dynamically allocate IRQ ranges on x86. · fd036dea
      John Baldwin authored
      Previously, x86 used static ranges of IRQ values for different types
      of I/O interrupts.  Interrupt pins on I/O APICs and 8259A PICs used
      IRQ values from 0 to 254.  MSI interrupts used a compile-time-defined
      range starting at 256, and Xen event channels used a
      compile-time-defined range after MSI.  Some recent systems have more
      than 255 I/O APIC interrupt pins which resulted in those IRQ values
      overflowing into the MSI range triggering an assertion failure.
      
      Replace statically assigned ranges with dynamic ranges.  Do a single
      pass computing the sizes of the IRQ ranges (PICs, MSI, Xen) to
      determine the total number of IRQs required.  Allocate the interrupt
      source and interrupt count arrays dynamically once this pass has
      completed.  To minimize runtime complexity these arrays are only sized
      once during bootup.  The PIC range is determined by the PICs present
      in the system.  The MSI and Xen ranges continue to use a fixed size,
      though this does make it possible to turn the MSI range size into a
      tunable in the future.
      
      As a result, various places are updated to use dynamic limits instead
      of constants.  In addition, the vmstat(8) utility has been taught to
      understand that some kernels may treat 'intrcnt' and 'intrnames' as
      pointers rather than arrays when extracting interrupt stats from a
      crashdump.  This is determined by the presence (vs absence) of a
      global 'nintrcnt' symbol.
      
      This change reverts r189404 which worked around a buggy BIOS which
      enumerated an I/O APIC twice (using the same memory mapped address for
      both entries but using an IRQ base of 256 for one entry and a valid
      IRQ base for the second entry).  Making the "base" of MSI IRQ values
      dynamic avoids the panic that r189404 worked around, and there may now
      be valid I/O APICs with an IRQ base above 256 which this workaround
      would incorrectly skip.
      
      If in the future the issue reported in PR 130483 reoccurs, we will
      have to add a pass over the I/O APIC entries in the MADT to detect
      duplicates using the memory mapped address and use some strategy to
      choose the "correct" one.
      
      While here, reserve room in intrcnts for the Hyper-V counters.
      
      PR:		229429, 130483
      Reviewed by:	kib, royger, cem
      Tested by:	royger (Xen), kib (DMAR)
      Approved by:	re (gjb)
      MFC after:	2 weeks
      Differential Revision:	https://reviews.freebsd.org/D16861
      fd036dea
  27. 19 Aug, 2018 1 commit
  28. 15 May, 2018 1 commit
    • Andriy Gapon's avatar
      calibrate lapic timer in native_lapic_setup · 7c5ccd2d
      Andriy Gapon authored
      The idea is to calibrate the LAPIC timer just once and only on boot,
      given that [at present] the timer constants are global and shared
      between all processors.
      
      My primary motivation is to fix a panic that can happen when dynamically
      switching to lapic timer.  The panic is caused by a recursion on
      et_hw_mtx when printing the calibration results to console.  See the
      review for the details of the panic.
      
      Also, the code should become slightly simpler and easier to read.  The
      previous code was racy too.  Multiple processors could start calibrating
      the global constants concurrently, although that seems to have been
      benign.
      
      Reviewed by:	kib, mav, jhb
      MFC after:	3 weeks
      Differential Revision: https://reviews.freebsd.org/D15422
      7c5ccd2d
  29. 13 Apr, 2018 1 commit
    • 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
  30. 28 Jan, 2018 1 commit
  31. 27 Jan, 2018 1 commit
    • Konstantin Belousov's avatar
      Fix native_lapic_ipi_alloc(). · e65c8c1a
      Konstantin Belousov authored
      When PTI is enabled, empty IDT slots point to rsvd_pti.
      
      Reported by:	Dexuan-BSD Cui <dexuan.bsd@gmail.com>
      Sponsored by:	The FreeBSD Foundation
      MFC after:	5 days
      e65c8c1a
  32. 17 Jan, 2018 1 commit
    • Konstantin Belousov's avatar
      PTI for amd64. · bd50262f
      Konstantin Belousov authored
      The implementation of the Kernel Page Table Isolation (KPTI) for
      amd64, first version. It provides a workaround for the 'meltdown'
      vulnerability.  PTI is turned off by default for now, enable with the
      loader tunable vm.pmap.pti=1.
      
      The pmap page table is split into kernel-mode table and user-mode
      table. Kernel-mode table is identical to the non-PTI table, while
      usermode table is obtained from kernel table by leaving userspace
      mappings intact, but only leaving the following parts of the kernel
      mapped:
      
          kernel text (but not modules text)
          PCPU
          GDT/IDT/user LDT/task structures
          IST stacks for NMI and doublefault handlers.
      
      Kernel switches to user page table before returning to usermode, and
      restores full kernel page table on the entry. Initial kernel-mode
      stack for PTI trampoline is allocated in PCPU, it is only 16
      qwords.  Kernel entry trampoline switches page tables. then the
      hardware trap frame is copied to the normal kstack, and execution
      continues.
      
      IST stacks are kept mapped and no trampoline is needed for
      NMI/doublefault, but of course page table switch is performed.
      
      On return to usermode, the trampoline is used again, iret frame is
      copied to the trampoline stack, page tables are switched and iretq is
      executed.  The case of iretq faulting due to the invalid usermode
      context is tricky, since the frame for fault is appended to the
      trampoline frame.  Besides copying the fault frame and original
      (corrupted) frame to kstack, the fault frame must be patched to make
      it look as if the fault occured on the kstack, see the comment in
      doret_iret detection code in trap().
      
      Currently kernel pages which are mapped during trampoline operation
      are identical for all pmaps.  They are registered using
      pmap_pti_add_kva().  Besides initial registrations done during boot,
      LDT and non-common TSS segments are registered if user requested their
      use.  In principle, they can be installed into kernel page table per
      pmap with some work.  Similarly, PCPU can be hidden from userspace
      mapping using trampoline PCPU page, but again I do not see much
      benefits besides complexity.
      
      PDPE pages for the kernel half of the user page tables are
      pre-allocated during boot because we need to know pml4 entries which
      are copied to the top-level paging structure page, in advance on a new
      pmap creation.  I enforce this to avoid iterating over the all
      existing pmaps if a new PDPE page is needed for PTI kernel mappings.
      The iteration is a known problematic operation on i386.
      
      The need to flush hidden kernel translations on the switch to user
      mode make global tables (PG_G) meaningless and even harming, so PG_G
      use is disabled for PTI case.  Our existing use of PCID is
      incompatible with PTI and is automatically disabled if PTI is
      enabled.  PCID can be forced on only for developer's benefit.
      
      MCE is known to be broken, it requires IST stack to operate completely
      correctly even for non-PTI case, and absolutely needs dedicated IST
      stack because MCE delivery while trampoline did not switched from PTI
      stack is fatal.  The fix is pending.
      
      Reviewed by:	markj (partially)
      Tested by:	pho (previous version)
      Discussed with:	jeff, jhb
      Sponsored by:	The FreeBSD Foundation
      MFC after:	2 weeks
      bd50262f
  33. 03 Jan, 2018 1 commit
    • Konstantin Belousov's avatar
      Use the new SDM-approved way to serialize x2APIC MSR writes. · af317aa4
      Konstantin Belousov authored
      SDM editions 64 and below stated that it is enough to use MFENCe or
      LFENCE to serialize x2APIC register writes.  New edition 65 requires
      either full serialization instruction or MFENCE;LFENCE sequence.  Use
      the later, FreeBSD needs serialization to ensure that writes done
      before IPI request are visible to the target IPI CPU.
      
      Sponsored by:	The FreeBSD Foundation
      MFC after:	1 week
      af317aa4
  34. 27 Nov, 2017 1 commit
    • 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
  35. 17 Sep, 2017 1 commit
    • Conrad Meyer's avatar
      MCA: Expand AMD Thresholding support to cover all banks · c50df68a
      Conrad Meyer authored
      When it was added in r314636, AMD Thresholding was hardcoded to only
      bank 4 (Northbridge) for some reason.  However, even on family 10h the
      MCAx_MISC register Valid/Present bits determine whether thresholding is
      supported on that bank.
      
      Expand thresholding support to monitor all monitorable banks.  This
      simplifies some of the logic and makes it more consistent with our Intel
      CMCI support.
      
      Reviewed by:	markj (earlier version)
      Sponsored by:	Dell EMC Isilon
      Differential Revision:	https://reviews.freebsd.org/D12321
      c50df68a
  36. 10 Aug, 2017 2 commits
    • Roger Pau Monné's avatar
      x86: make the arrays that depend on MAX_APIC_ID dynamic · 84525e55
      Roger Pau Monné authored
      So that MAX_APIC_ID can be bumped without wasting memory.
      
      Note that the usage of MAX_APIC_ID in the SRAT parsing forces the
      parser to allocate memory directly from the phys_avail physical memory
      array, which is not the best approach probably, but I haven't found
      any other way to allocate memory so early in boot. This memory is not
      returned to the system afterwards, but at least it's sized according
      to the maximum APIC ID found in the MADT table.
      
      Sponsored by:		Citrix Systems R&D
      MFC after:		1 month
      Reviewed by:		kib
      Differential revision:	https://reviews.freebsd.org/D11912
      84525e55
    • 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
  37. 27 Mar, 2017 1 commit
    • Andriy Gapon's avatar
      revert r315959 because it causes build problems · 978f3da1
      Andriy Gapon authored
      The change introduced a dependency between genassym.c and header files
      generated from .m files, but that dependency is not specified in the
      make files.
      
      Also, the change could be not as useful as I thought it was.
      
      Reported by:	dchagin, Manfred Antar <null@pozo.com>, and many others
      978f3da1
  38. 25 Mar, 2017 1 commit
    • Andriy Gapon's avatar
      specific end of interrupt implementation for AMD Local APIC · a7b4c009
      Andriy Gapon authored
      The change is more intrusive than I would like because the feature
      requires that a vector number is written to a special register.
      Thus, now the vector number has to be provided to lapic_eoi().
      It was readily available in the IO-APIC and MSI cases, but the IPI
      handlers required more work.
      Also, we now store the VMM IPI number in a global variable, so that it
      is available to the justreturn handler for the same reason.
      
      Reviewed by:	kib
      MFC after:	6 weeks
      Differential Revision: https://reviews.freebsd.org/D9880
      a7b4c009