1. 08 Sep, 2019 1 commit
    • Jan Stancek's avatar
      x86/timer: Force PIT initialization when !X86_FEATURE_ARAT · afa8b475
      Jan Stancek authored
      KVM guests with commit c8c40767 ("x86/timer: Skip PIT initialization on
      modern chipsets") applied to guest kernel have been observed to have
      unusually higher CPU usage with symptoms of increase in vm exits for HLT
      and MSW_WRITE (MSR_IA32_TSCDEADLINE).
      
      This is caused by older QEMUs lacking support for X86_FEATURE_ARAT.  lapic
      clock retains CLOCK_EVT_FEAT_C3STOP and nohz stays inactive.  There's no
      usable broadcast device either.
      
      Do the PIT initialization if guest CPU lacks X86_FEATURE_ARAT.  On real
      hardware it shouldn't matter as ARAT and DEADLINE come together.
      
      Fixes: c8c40767
      
       ("x86/timer: Skip PIT initialization on modern chipsets")
      Signed-off-by: default avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      afa8b475
  2. 07 Sep, 2019 1 commit
    • Linus Torvalds's avatar
      Revert "x86/apic: Include the LDR when clearing out APIC registers" · 950b07c1
      Linus Torvalds authored
      This reverts commit 558682b5.
      
      Chris Wilson reports that it breaks his CPU hotplug test scripts.  In
      particular, it breaks offlining and then re-onlining the boot CPU, which
      we treat specially (and the BIOS does too).
      
      The symptoms are that we can offline the CPU, but it then does not come
      back online again:
      
          smpboot: CPU 0 is now offline
          smpboot: Booting Node 0 Processor 0 APIC 0x0
          smpboot: do_boot_cpu failed(-1) to wakeup CPU#0
      
      Thomas says he knows why it's broken (my personal suspicion: our magic
      handling of the "cpu0_logical_apicid" thing), but for 5.3 the right fix
      is to just revert it, since we've never touched the LDR bits before, and
      it's not worth the risk to do anything else at this stage.
      
      [ Hotpluging of the boot CPU is special anyway, and should be off by
        default. See the "BOOTPARAM_HOTPLUG_CPU0" config option and the
        cpu0_hotplug kernel parameter.
      
        In general you should not do it, and it has various known limitations
        (hibernate and suspend require the boot CPU, for example).
      
        But it should work, even if the boot CPU is special and needs careful
        treatment       - Linus ]
      
      Link: https://lore.kernel.org/lkml/156785100521.13300.14461504732265570003@skylake-alporthouse-com/
      
      Reported-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Bandan Das <bsd@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      950b07c1
  3. 28 Aug, 2019 4 commits
  4. 26 Aug, 2019 1 commit
    • Bandan Das's avatar
      x86/apic: Include the LDR when clearing out APIC registers · 558682b5
      Bandan Das authored
      
      
      Although APIC initialization will typically clear out the LDR before
      setting it, the APIC cleanup code should reset the LDR.
      
      This was discovered with a 32-bit KVM guest jumping into a kdump
      kernel. The stale bits in the LDR triggered a bug in the KVM APIC
      implementation which caused the destination mapping for VCPUs to be
      corrupted.
      
      Note that this isn't intended to paper over the KVM APIC bug. The kernel
      has to clear the LDR when resetting the APIC registers except when X2APIC
      is enabled.
      
      This lacks a Fixes tag because missing to clear LDR goes way back into pre
      git history.
      
      [ tglx: Made x2apic_enabled a function call as required ]
      Signed-off-by: default avatarBandan Das <bsd@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190826101513.5080-3-bsd@redhat.com
      558682b5
  5. 19 Aug, 2019 1 commit
  6. 07 Aug, 2019 1 commit
  7. 25 Jul, 2019 4 commits
    • Thomas Gleixner's avatar
      x86/hotplug: Silence APIC and NMI when CPU is dead · 60dcaad5
      Thomas Gleixner authored
      
      
      In order to support IPI/NMI broadcasting via the shorthand mechanism side
      effects of shorthands need to be mitigated:
      
       Shorthand IPIs and NMIs hit all CPUs including unplugged CPUs
      
      Neither of those can be handled on unplugged CPUs for obvious reasons.
      
      It would be trivial to just fully disable the APIC via the enable bit in
      MSR_APICBASE. But that's not possible because clearing that bit on systems
      based on the 3 wire APIC bus would require a hardware reset to bring it
      back as the APIC would lose track of bus arbitration. On systems with FSB
      delivery APICBASE could be disabled, but it has to be guaranteed that no
      interrupt is sent to the APIC while in that state and it's not clear from
      the SDM whether it still responds to INIT/SIPI messages.
      
      Therefore stay on the safe side and switch the APIC into soft disabled mode
      so it won't deliver any regular vector to the CPU.
      
      NMIs are still propagated to the 'dead' CPUs. To mitigate that add a check
      for the CPU being offline on early nmi entry and if so bail.
      
      Note, this cannot use the stop/restart_nmi() magic which is used in the
      alternatives code. A dead CPU cannot invoke nmi_enter() or anything else
      due to RCU and other reasons.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1907241723290.1791@nanos.tec.linutronix.de
      60dcaad5
    • Thomas Gleixner's avatar
      x86/apic: Make apic_pending_intr_clear() more robust · cc8bf191
      Thomas Gleixner authored
      
      
      In course of developing shorthand based IPI support issues with the
      function which tries to clear eventually pending ISR bits in the local APIC
      were observed.
      
        1) O-day testing triggered the WARN_ON() in apic_pending_intr_clear().
      
           This warning is emitted when the function fails to clear pending ISR
           bits or observes pending IRR bits which are not delivered to the CPU
           after the stale ISR bit(s) are ACK'ed.
      
           Unfortunately the function only emits a WARN_ON() and fails to dump
           the IRR/ISR content. That's useless for debugging.
      
           Feng added spot on debug printk's which revealed that the stale IRR
           bit belonged to the APIC timer interrupt vector, but adding ad hoc
           debug code does not help with sporadic failures in the field.
      
           Rework the loop so the full IRR/ISR contents are saved and on failure
           dumped.
      
        2) The loop termination logic is interesting at best.
      
           If the machine has no TSC or cpu_khz is not known yet it tries 1
           million times to ack stale IRR/ISR bits. What?
      
           With TSC it uses the TSC to calculate the loop termination. It takes a
           timestamp at entry and terminates the loop when:
      
           	  (rdtsc() - start_timestamp) >= (cpu_hkz << 10)
      
           That's roughly one second.
      
           Both methods are problematic. The APIC has 256 vectors, which means
           that in theory max. 256 IRR/ISR bits can be set. In practice this is
           impossible and the chance that more than a few bits are set is close
           to zero.
      
           With the pure loop based approach the 1 million retries are complete
           overkill.
      
           With TSC this can terminate too early in a guest which is running on a
           heavily loaded host even with only a couple of IRR/ISR bits set. The
           reason is that after acknowledging the highest priority ISR bit,
           pending IRRs must get serviced first before the next round of
           acknowledge can take place as the APIC (real and virtualized) does not
           honour EOI without a preceeding interrupt on the CPU. And every APIC
           read/write takes a VMEXIT if the APIC is virtualized. While trying to
           reproduce the issue 0-day reported it was observed that the guest was
           scheduled out long enough under heavy load that it terminated after 8
           iterations.
      
           Make the loop terminate after 512 iterations. That's plenty enough
           in any case and does not take endless time to complete.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20190722105219.158847694@linutronix.de
      cc8bf191
    • Thomas Gleixner's avatar
      x86/apic: Soft disable APIC before initializing it · 2640da4c
      Thomas Gleixner authored
      
      
      If the APIC was already enabled on entry of setup_local_APIC() then
      disabling it soft via the SPIV register makes a lot of sense.
      
      That masks all LVT entries and brings it into a well defined state.
      
      Otherwise previously enabled LVTs which are not touched in the setup
      function stay unmasked and might surprise the just booting kernel.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20190722105219.068290579@linutronix.de
      2640da4c
    • Thomas Gleixner's avatar
      x86/apic: Invoke perf_events_lapic_init() after enabling APIC · 39c89dff
      Thomas Gleixner authored
      
      
      If the APIC is soft disabled then unmasking an LVT entry does not work and
      the write is ignored. perf_events_lapic_init() tries to do so.
      
      Move the invocation after the point where the APIC has been enabled.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20190722105218.962517234@linutronix.de
      39c89dff
  8. 22 Jul, 2019 1 commit
  9. 16 Jul, 2019 1 commit
    • Qian Cai's avatar
      x86/apic: Silence -Wtype-limits compiler warnings · ec633558
      Qian Cai authored
      
      
      There are many compiler warnings like this,
      
      In file included from ./arch/x86/include/asm/smp.h:13,
                       from ./arch/x86/include/asm/mmzone_64.h:11,
                       from ./arch/x86/include/asm/mmzone.h:5,
                       from ./include/linux/mmzone.h:969,
                       from ./include/linux/gfp.h:6,
                       from ./include/linux/mm.h:10,
                       from arch/x86/kernel/apic/io_apic.c:34:
      arch/x86/kernel/apic/io_apic.c: In function 'check_timer':
      ./arch/x86/include/asm/apic.h:37:11: warning: comparison of unsigned
      expression >= 0 is always true [-Wtype-limits]
         if ((v) <= apic_verbosity) \
                 ^~
      arch/x86/kernel/apic/io_apic.c:2160:2: note: in expansion of macro
      'apic_printk'
        apic_printk(APIC_QUIET, KERN_INFO "..TIMER: vector=0x%02X "
        ^~~~~~~~~~~
      ./arch/x86/include/asm/apic.h:37:11: warning: comparison of unsigned
      expression >= 0 is always true [-Wtype-limits]
         if ((v) <= apic_verbosity) \
                 ^~
      arch/x86/kernel/apic/io_apic.c:2207:4: note: in expansion of macro
      'apic_printk'
          apic_printk(APIC_QUIET, KERN_ERR "..MP-BIOS bug: "
          ^~~~~~~~~~~
      
      APIC_QUIET is 0, so silence them by making apic_verbosity type int.
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/1562621805-24789-1-git-send-email-cai@lca.pw
      ec633558
  10. 03 Jul, 2019 1 commit
    • Thomas Gleixner's avatar
      x86/irq: Seperate unused system vectors from spurious entry again · f8a8fe61
      Thomas Gleixner authored
      Quite some time ago the interrupt entry stubs for unused vectors in the
      system vector range got removed and directly mapped to the spurious
      interrupt vector entry point.
      
      Sounds reasonable, but it's subtly broken. The spurious interrupt vector
      entry point pushes vector number 0xFF on the stack which makes the whole
      logic in __smp_spurious_interrupt() pointless.
      
      As a consequence any spurious interrupt which comes from a vector != 0xFF
      is treated as a real spurious interrupt (vector 0xFF) and not
      acknowledged. That subsequently stalls all interrupt vectors of equal and
      lower priority, which brings the system to a grinding halt.
      
      This can happen because even on 64-bit the system vector space is not
      guaranteed to be fully populated. A full compile time handling of the
      unused vectors is not possible because quite some of them are conditonally
      populated at runtime.
      
      Bring the entry stubs back, which wastes 160 bytes if all stubs are unused,
      but gains the proper handling back. There is no point to selectively spare
      some of the stubs which are known at compile time as the required code in
      the IDT management would be way larger and convoluted.
      
      Do not route the spurious entries through common_interrupt and do_IRQ() as
      the original code did. Route it to smp_spurious_interrupt() which evaluates
      the vector number and acts accordingly now that the real vector numbers are
      handed in.
      
      Fixup the pr_warn so the actual spurious vector (0xff) is clearly
      distiguished from the other vectors and also note for the vectored case
      whether it was pending in the ISR or not.
      
       "Spurious APIC interrupt (vector 0xFF) on CPU#0, should never happen."
       "Spurious interrupt vector 0xed on CPU#1. Acked."
       "Spurious interrupt vector 0xee on CPU#1. Not pending!."
      
      Fixes: 2414e021
      
       ("x86: Avoid building unused IRQ entry stubs")
      Reported-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Jan Beulich <jbeulich@suse.com>
      Link: https://lkml.kernel.org/r/20190628111440.550568228@linutronix.de
      f8a8fe61
  11. 29 Jun, 2019 1 commit
    • Thomas Gleixner's avatar
      x86/timer: Skip PIT initialization on modern chipsets · c8c40767
      Thomas Gleixner authored
      
      
      Recent Intel chipsets including Skylake and ApolloLake have a special
      ITSSPRC register which allows the 8254 PIT to be gated.  When gated, the
      8254 registers can still be programmed as normal, but there are no IRQ0
      timer interrupts.
      
      Some products such as the Connex L1430 and exone go Rugged E11 use this
      register to ship with the PIT gated by default. This causes Linux to fail
      to boot:
      
        Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with
        apic=debug and send a report.
      
      The panic happens before the framebuffer is initialized, so to the user, it
      appears as an early boot hang on a black screen.
      
      Affected products typically have a BIOS option that can be used to enable
      the 8254 and make Linux work (Chipset -> South Cluster Configuration ->
      Miscellaneous Configuration -> 8254 Clock Gating), however it would be best
      to make Linux support the no-8254 case.
      
      Modern sytems allow to discover the TSC and local APIC timer frequencies,
      so the calibration against the PIT is not required. These systems have
      always running timers and the local APIC timer works also in deep power
      states.
      
      So the setup of the PIT including the IO-APIC timer interrupt delivery
      checks are a pointless exercise.
      
      Skip the PIT setup and the IO-APIC timer interrupt checks on these systems,
      which avoids the panic caused by non ticking PITs and also speeds up the
      boot process.
      
      Thanks to Daniel for providing the changelog, initial analysis of the
      problem and testing against a variety of machines.
      Reported-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarDaniel Drake <drake@endlessm.com>
      Cc: bp@alien8.de
      Cc: hpa@zytor.com
      Cc: linux@endlessm.com
      Cc: rafael.j.wysocki@intel.com
      Cc: hdegoede@redhat.com
      Link: https://lkml.kernel.org/r/20190628072307.24678-1-drake@endlessm.com
      c8c40767
  12. 22 Jun, 2019 1 commit
  13. 16 Jun, 2019 1 commit
  14. 21 May, 2019 1 commit
  15. 09 May, 2019 1 commit
  16. 25 Apr, 2019 1 commit
  17. 08 Dec, 2018 1 commit
    • Borislav Petkov's avatar
      x86/kernel: Fix more -Wmissing-prototypes warnings · ad3bc25a
      Borislav Petkov authored
      
      
      ... with the goal of eventually enabling -Wmissing-prototypes by
      default. At least on x86.
      
      Make functions static where possible, otherwise add prototypes or make
      them visible through includes.
      
      asm/trace/ changes courtesy of Steven Rostedt <rostedt@goodmis.org>.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Reviewed-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> # ACPI + cpufreq bits
      Cc: Andrew Banman <andrew.banman@hpe.com>
      Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Mike Travis <mike.travis@hpe.com>
      Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yi Wang <wang.yi59@zte.com.cn>
      Cc: linux-acpi@vger.kernel.org
      ad3bc25a
  18. 31 Oct, 2018 1 commit
  19. 27 Sep, 2018 1 commit
  20. 14 Aug, 2018 1 commit
  21. 05 Aug, 2018 1 commit
    • Nicolai Stange's avatar
      x86: Don't include linux/irq.h from asm/hardirq.h · 447ae316
      Nicolai Stange authored
      
      
      The next patch in this series will have to make the definition of
      irq_cpustat_t available to entering_irq().
      
      Inclusion of asm/hardirq.h into asm/apic.h would cause circular header
      dependencies like
      
        asm/smp.h
          asm/apic.h
            asm/hardirq.h
              linux/irq.h
                linux/topology.h
                  linux/smp.h
                    asm/smp.h
      
      or
      
        linux/gfp.h
          linux/mmzone.h
            asm/mmzone.h
              asm/mmzone_64.h
                asm/smp.h
                  asm/apic.h
                    asm/hardirq.h
                      linux/irq.h
                        linux/irqdesc.h
                          linux/kobject.h
                            linux/sysfs.h
                              linux/kernfs.h
                                linux/idr.h
                                  linux/gfp.h
      
      and others.
      
      This causes compilation errors because of the header guards becoming
      effective in the second inclusion: symbols/macros that had been defined
      before wouldn't be available to intermediate headers in the #include chain
      anymore.
      
      A possible workaround would be to move the definition of irq_cpustat_t
      into its own header and include that from both, asm/hardirq.h and
      asm/apic.h.
      
      However, this wouldn't solve the real problem, namely asm/harirq.h
      unnecessarily pulling in all the linux/irq.h cruft: nothing in
      asm/hardirq.h itself requires it. Also, note that there are some other
      archs, like e.g. arm64, which don't have that #include in their
      asm/hardirq.h.
      
      Remove the linux/irq.h #include from x86' asm/hardirq.h.
      
      Fix resulting compilation errors by adding appropriate #includes to *.c
      files as needed.
      
      Note that some of these *.c files could be cleaned up a bit wrt. to their
      set of #includes, but that should better be done from separate patches, if
      at all.
      Signed-off-by: default avatarNicolai Stange <nstange@suse.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      447ae316
  22. 30 Jul, 2018 1 commit
  23. 24 Jul, 2018 1 commit
  24. 02 Jul, 2018 1 commit
    • Thomas Gleixner's avatar
      Revert "x86/apic: Ignore secondary threads if nosmt=force" · 506a66f3
      Thomas Gleixner authored
      Dave Hansen reported, that it's outright dangerous to keep SMT siblings
      disabled completely so they are stuck in the BIOS and wait for SIPI.
      
      The reason is that Machine Check Exceptions are broadcasted to siblings and
      the soft disabled sibling has CR4.MCE = 0. If a MCE is delivered to a
      logical core with CR4.MCE = 0, it asserts IERR#, which shuts down or
      reboots the machine. The MCE chapter in the SDM contains the following
      blurb:
      
          Because the logical processors within a physical package are tightly
          coupled with respect to shared hardware resources, both logical
          processors are notified of machine check errors that occur within a
          given physical processor. If machine-check exceptions are enabled when
          a fatal error is reported, all the logical processors within a physical
          package are dispatched to the machine-check exception handler. If
          machine-check exceptions are disabled, the logical processors enter the
          shutdown state and assert the IERR# signal. When enabling machine-check
          exceptions, the MCE flag in control register CR4 should be set for each
          logical processor.
      
      Reverting the commit which ignores siblings at enumeration time solves only
      half of the problem. The core cpuhotplug logic needs to be adjusted as
      well.
      
      This thoughtful engineered mechanism also turns the boot process on all
      Intel HT enabled systems into a MCE lottery. MCE is enabled on the boot CPU
      before the secondary CPUs are brought up. Depending on the number of
      physical cores the window in which this situation can happen is smaller or
      larger. On a HSW-EX it's about 750ms:
      
      MCE is enabled on the boot CPU:
      
      [    0.244017] mce: CPU supports 22 MCE banks
      
      The corresponding sibling #72 boots:
      
      [    1.008005] .... node  #0, CPUs:    #72
      
      That means if an MCE hits on physical core 0 (logical CPUs 0 and 72)
      between these two points the machine is going to shutdown. At least it's a
      known safe state.
      
      It's obvious that the early boot can be hit by an MCE as well and then runs
      into the same situation because MCEs are not yet enabled on the boot CPU.
      But after enabling them on the boot CPU, it does not make any sense to
      prevent the kernel from recovering.
      
      Adjust the nosmt kernel parameter documentation as well.
      
      Reverts: 2207def7
      
       ("x86/apic: Ignore secondary threads if nosmt=force")
      Reported-by: default avatarDave Hansen <dave.hansen@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarTony Luck <tony.luck@intel.com>
      506a66f3
  25. 21 Jun, 2018 2 commits
    • Thomas Gleixner's avatar
      x86/apic: Ignore secondary threads if nosmt=force · 2207def7
      Thomas Gleixner authored
      
      
      nosmt on the kernel command line merely prevents the onlining of the
      secondary SMT siblings.
      
      nosmt=force makes the APIC detection code ignore the secondary SMT siblings
      completely, so they even do not show up as possible CPUs. That reduces the
      amount of memory allocations for per cpu variables and saves other
      resources from being allocated too large.
      
      This is not fully equivalent to disabling SMT in the BIOS because the low
      level SMT enabling in the BIOS can result in partitioning of resources
      between the siblings, which is not undone by just ignoring them. Some CPUs
      can use the full resources when their sibling is not onlined, but this is
      depending on the CPU family and model and it's not well documented whether
      this applies to all partitioned resources. That means depending on the
      workload disabling SMT in the BIOS might result in better performance.
      
      Linus analysis of the Intel manual:
      
        The intel optimization manual is not very clear on what the partitioning
        rules are.
      
        I find:
      
          "In general, the buffers for staging instructions between major pipe
           stages  are partitioned. These buffers include µop queues after the
           execution trace cache, the queues after the register rename stage, the
           reorder buffer which stages instructions for retirement, and the load
           and store buffers.
      
           In the case of load and store buffers, partitioning also provided an
           easier implementation to maintain memory ordering for each logical
           processor and detect memory ordering violations"
      
        but some of that partitioning may be relaxed if the HT thread is "not
        active":
      
          "In Intel microarchitecture code name Sandy Bridge, the micro-op queue
           is statically partitioned to provide 28 entries for each logical
           processor,  irrespective of software executing in single thread or
           multiple threads. If one logical processor is not active in Intel
           microarchitecture code name Ivy Bridge, then a single thread executing
           on that processor  core can use the 56 entries in the micro-op queue"
      
        but I do not know what "not active" means, and how dynamic it is. Some of
        that partitioning may be entirely static and depend on the early BIOS
        disabling of HT, and even if we park the cores, the resources will just be
        wasted.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      2207def7
    • Thomas Gleixner's avatar
      x86/smp: Provide topology_is_primary_thread() · 6a4d2657
      Thomas Gleixner authored
      
      
      If the CPU is supporting SMT then the primary thread can be found by
      checking the lower APIC ID bits for zero. smp_num_siblings is used to build
      the mask for the APIC ID bits which need to be taken into account.
      
      This uses the MPTABLE or ACPI/MADT supplied APIC ID, which can be different
      than the initial APIC ID in CPUID. But according to AMD the lower bits have
      to be consistent. Intel gave a tentative confirmation as well.
      
      Preparatory patch to support disabling SMT at boot/runtime.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      6a4d2657
  26. 01 Mar, 2018 3 commits
  27. 17 Feb, 2018 1 commit
    • Baoquan He's avatar
      x86/apic: Set up through-local-APIC mode on the boot CPU if 'noapic' specified · bee3204e
      Baoquan He authored
      Currently the kdump kernel becomes very slow if 'noapic' is specified.
      Normal kernel doesn't have this bug.
      
      Kernel parameter 'noapic' is used to disable IO-APIC in system for
      testing or special purpose. Here the root cause is that in kdump
      kernel LAPIC is disabled since commit:
      
        522e6646 ("x86/apic: Disable I/O APIC before shutdown of the local APIC")
      
      In this case we need set up through-local-APIC on boot CPU in
      setup_local_APIC().
      
      In normal kernel the legacy irq mode is enabled by the BIOS. If
      it is virtual wire mode, the local-APIC has been enabled and set as
      through-local-APIC.
      
      Though we fixed the regression introduced by commit 522e6646
      
      ,
      to further improve robustness set up the through-local-APIC mode
      explicitly, do not rely on the default boot IRQ mode.
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      Reviewed-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: douly.fnst@cn.fujitsu.com
      Cc: joro@8bytes.org
      Cc: prarit@redhat.com
      Cc: uobergfe@redhat.com
      Link: http://lkml.kernel.org/r/20180214054656.3780-7-bhe@redhat.com
      
      
      [ Rewrote the changelog. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      bee3204e
  28. 16 Feb, 2018 1 commit
  29. 15 Feb, 2018 1 commit
  30. 14 Jan, 2018 1 commit
  31. 28 Dec, 2017 1 commit