1. 15 1月, 2015 6 次提交
    • J
      x86/apic: Refine enable_IR_x2apic() and related functions · 07806c50
      Jiang Liu 提交于
      Refine enable_IR_x2apic() and related functions for better readability.
      
      [ tglx: Removed the XAPIC mode change and split it out into a seperate
        	patch. Added comments. ]
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Link: http://lkml.kernel.org/r/1420615903-28253-8-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      07806c50
    • J
      x86/apic: Correctly detect X2APIC status in function enable_IR() · 89356cf2
      Jiang Liu 提交于
      X2APIC will be disabled if user specifies "nox2apic" on kernel command
      line, even when x2apic_preenabled is true. So correctly detect X2APIC
      status by using x2apic_enabled() instead of x2apic_preenabled.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Link: http://lkml.kernel.org/r/1420615903-28253-7-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      89356cf2
    • J
      x86/apic: Kill useless variable x2apic_enabled in function enable_IR_x2apic() · 7f530a27
      Jiang Liu 提交于
      Local variable x2apic_enabled has been assigned to but never referred,
      so kill it.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Link: http://lkml.kernel.org/r/1420615903-28253-6-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      7f530a27
    • J
      x86/apic: Panic if kernel doesn't support x2apic but BIOS has enabled x2apic · 2599094f
      Jiang Liu 提交于
      When kernel doesn't support X2APIC but BIOS has enabled X2APIC, system
      may panic or hang without useful messages. On the other hand, it's
      hard to dynamically disable X2APIC when CONFIG_X86_X2APIC is disabled.
      So panic with a clear message in such a case.
      
      Now system panics as below when X2APIC is disabled and interrupt remapping
      is enabled:
      [    0.316118] LAPIC pending interrupts after 512 EOI
      [    0.322126] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
      [    0.368655] Kernel panic - not syncing: timer doesn't work through Interrupt-remapped IO-APIC
      [    0.378300] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0+ #340
      [    0.385300] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIN1.86B.0051.L05.1406240953 06/24/2014
      [    0.396997]  ffff88046dc03000 ffff88046c307dd8 ffffffff8179dada 00000000000043f2
      [    0.405629]  ffffffff81a92158 ffff88046c307e58 ffffffff8179b757 0000000000000002
      [    0.414261]  0000000000000008 ffff88046c307e68 ffff88046c307e08 ffffffff813ad82b
      [    0.422890] Call Trace:
      [    0.425711]  [<ffffffff8179dada>] dump_stack+0x45/0x57
      [    0.431533]  [<ffffffff8179b757>] panic+0xc1/0x1f5
      [    0.436978]  [<ffffffff813ad82b>] ? delay_tsc+0x3b/0x70
      [    0.442910]  [<ffffffff8166fa2c>] panic_if_irq_remap+0x1c/0x20
      [    0.449524]  [<ffffffff81d73645>] setup_IO_APIC+0x405/0x82e
      [    0.464979]  [<ffffffff81d6fcc2>] native_smp_prepare_cpus+0x2d9/0x31c
      [    0.472274]  [<ffffffff81d5d0ac>] kernel_init_freeable+0xd6/0x223
      [    0.479170]  [<ffffffff81792ad0>] ? rest_init+0x80/0x80
      [    0.485099]  [<ffffffff81792ade>] kernel_init+0xe/0xf0
      [    0.490932]  [<ffffffff817a537c>] ret_from_fork+0x7c/0xb0
      [    0.497054]  [<ffffffff81792ad0>] ? rest_init+0x80/0x80
      [    0.502983] ---[ end Kernel panic - not syncing: timer doesn't work through Interrupt-remapped IO-APIC
      
      System hangs as below when X2APIC and interrupt remapping are both disabled:
      [    1.102782] pci 0000:00:02.0: System wakeup disabled by ACPI
      [    1.109351] pci 0000:00:03.0: System wakeup disabled by ACPI
      [    1.115915] pci 0000:00:03.2: System wakeup disabled by ACPI
      [    1.122479] pci 0000:00:03.3: System wakeup disabled by ACPI
      [    1.132274] pci 0000:00:1c.0: Enabling MPC IRBNCE
      [    1.137620] pci 0000:00:1c.0: Intel PCH root port ACS workaround enabled
      [    1.145239] pci 0000:00:1c.0: System wakeup disabled by ACPI
      [    1.151790] pci 0000:00:1c.7: Enabling MPC IRBNCE
      [    1.157128] pci 0000:00:1c.7: Intel PCH root port ACS workaround enabled
      [    1.164748] pci 0000:00:1c.7: System wakeup disabled by ACPI
      [    1.171447] pci 0000:00:1e.0: System wakeup disabled by ACPI
      [    1.178612] acpiphp: Slot [8] registered
      [    1.183095] pci 0000:00:02.0: PCI bridge to [bus 01]
      [    1.188867] acpiphp: Slot [2] registered
      
      With this patch applied, the system panics in both cases with a proper
      panic message.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Link: http://lkml.kernel.org/r/1420615903-28253-5-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      2599094f
    • T
      x86/apic: Clear stale x2apic mode · f7ccadac
      Thomas Gleixner 提交于
      If x2apic got disabled on the kernel command line, then the following
      issue can happen:
      
      enable_IR_x2apic()
         ....
         x2apic_mode = 1;
         enable_x2apic();
      
           if (x2apic_disabled) {
      	__disable_x2apic();
      	return;
           }
      
      That leaves X2APIC disabled in hardware, but x2apic_mode stays 1. So
      all other code which checks x2apic_mode gets the wrong information.
      
      Set x2apic_mode to 0 after disabling it in hardware.
      
      This is just a hotfix. The proper solution is to rework this code so
      it has seperate functions for the initial setup on the boot processor
      and the secondary cpus, but that's beyond the scope of this fix.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      f7ccadac
    • T
      iommu, x86: Restructure setup of the irq remapping feature · a1dafe85
      Thomas Gleixner 提交于
      enable_IR_x2apic() calls setup_irq_remapping_ops() which by default
      installs the intel dmar remapping ops and then calls the amd iommu irq
      remapping prepare callback to figure out whether we are running on an
      AMD machine with irq remapping hardware.
      
      Right after that it calls irq_remapping_prepare() which pointlessly
      checks:
      	if (!remap_ops || !remap_ops->prepare)
                     return -ENODEV;
      and then calls
      
          remap_ops->prepare()
      
      which is silly in the AMD case as it got called from
      setup_irq_remapping_ops() already a few microseconds ago.
      
      Simplify this and just collapse everything into
      irq_remapping_prepare().
      
      The irq_remapping_prepare() remains still silly as it assigns blindly
      the intel ops, but that's not scope of this patch.
      
      The scope here is to move the preperatory work, i.e. memory
      allocations out of the atomic section which is required to enable irq
      remapping.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NBorislav Petkov <bp@alien8.de>
      Acked-and-tested-by: NJoerg Roedel <joro@8bytes.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Cc: x86@kernel.org
      Link: http://lkml.kernel.org/r/20141205084147.232633738@linutronix.de
      Link: http://lkml.kernel.org/r/1420615903-28253-2-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      a1dafe85
  2. 16 12月, 2014 1 次提交
    • J
      x86: Avoid building unused IRQ entry stubs · 2414e021
      Jan Beulich 提交于
      When X86_LOCAL_APIC (i.e. unconditionally on x86-64),
      first_system_vector will never end up being higher than
      LOCAL_TIMER_VECTOR (0xef), and hence building stubs for vectors
      0xef...0xff is pointlessly reducing code density. Deal with this at
      build time already.
      
      Taking into consideration that X86_64 implies X86_LOCAL_APIC, also
      simplify (and hence make easier to read and more consistent with the
      change done here) some #if-s in arch/x86/kernel/irqinit.c.
      
      While we could further improve the packing of the IRQ entry stubs (the
      four ones now left in the last set could be fit into the four padding
      bytes each of the final four sets have) this doesn't seem to provide
      any real benefit: Both irq_entries_start and common_interrupt getting
      cache line aligned, eliminating the 30th set would just produce 32
      bytes of padding between the 29th and common_interrupt.
      
      [ tglx: Folded lguest fix from Dan Carpenter ]
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: lguest@lists.ozlabs.org
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Link: http://lkml.kernel.org/r/54574D5F0200007800044389@mail.emea.novell.com
      Link: http://lkml.kernel.org/r/20141115185718.GB6530@mwandaSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      2414e021
  3. 23 10月, 2014 1 次提交
  4. 27 8月, 2014 1 次提交
    • C
      x86: Replace __get_cpu_var uses · 89cbc767
      Christoph Lameter 提交于
      __get_cpu_var() is used for multiple purposes in the kernel source. One of
      them is address calculation via the form &__get_cpu_var(x).  This calculates
      the address for the instance of the percpu variable of the current processor
      based on an offset.
      
      Other use cases are for storing and retrieving data from the current
      processors percpu area.  __get_cpu_var() can be used as an lvalue when
      writing data or on the right side of an assignment.
      
      __get_cpu_var() is defined as :
      
      #define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
      
      __get_cpu_var() always only does an address determination. However, store
      and retrieve operations could use a segment prefix (or global register on
      other platforms) to avoid the address calculation.
      
      this_cpu_write() and this_cpu_read() can directly take an offset into a
      percpu area and use optimized assembly code to read and write per cpu
      variables.
      
      This patch converts __get_cpu_var into either an explicit address
      calculation using this_cpu_ptr() or into a use of this_cpu operations that
      use the offset.  Thereby address calculations are avoided and less registers
      are used when code is generated.
      
      Transformations done to __get_cpu_var()
      
      1. Determine the address of the percpu instance of the current processor.
      
      	DEFINE_PER_CPU(int, y);
      	int *x = &__get_cpu_var(y);
      
          Converts to
      
      	int *x = this_cpu_ptr(&y);
      
      2. Same as #1 but this time an array structure is involved.
      
      	DEFINE_PER_CPU(int, y[20]);
      	int *x = __get_cpu_var(y);
      
          Converts to
      
      	int *x = this_cpu_ptr(y);
      
      3. Retrieve the content of the current processors instance of a per cpu
      variable.
      
      	DEFINE_PER_CPU(int, y);
      	int x = __get_cpu_var(y)
      
         Converts to
      
      	int x = __this_cpu_read(y);
      
      4. Retrieve the content of a percpu struct
      
      	DEFINE_PER_CPU(struct mystruct, y);
      	struct mystruct x = __get_cpu_var(y);
      
         Converts to
      
      	memcpy(&x, this_cpu_ptr(&y), sizeof(x));
      
      5. Assignment to a per cpu variable
      
      	DEFINE_PER_CPU(int, y)
      	__get_cpu_var(y) = x;
      
         Converts to
      
      	__this_cpu_write(y, x);
      
      6. Increment/Decrement etc of a per cpu variable
      
      	DEFINE_PER_CPU(int, y);
      	__get_cpu_var(y)++
      
         Converts to
      
      	__this_cpu_inc(y)
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86@kernel.org
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      89cbc767
  5. 31 7月, 2014 2 次提交
  6. 14 7月, 2014 1 次提交
  7. 22 6月, 2014 1 次提交
    • J
      x86, mpparse: Simplify arch/x86/include/asm/mpspec.h · a491cc90
      Jiang Liu 提交于
      Simplify arch/x86/include/asm/mpspec.h by
      1) Change max_physical_apicid to static as it's only used in apic.c.
      2) Kill declaration of mpc_default_type, it's never defined.
      3) Delete default_acpi_madt_oem_check(), it has already been declared
         in apic.h.
      4) Make default_acpi_madt_oem_check() depends on CONFIG_X86_LOCAL_APIC
         instead of CONFIG_X86_64 to support i386.
      5) Change mp_override_legacy_irq(), mp_config_acpi_legacy_irqs() and
         mp_register_gsi() as static because they are only used in acpi/boot.c.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Andi Kleen <ak@linux.intel.com>
      Link: http://lkml.kernel.org/r/1402302011-23642-4-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      a491cc90
  8. 01 4月, 2014 1 次提交
    • M
      x86/apic: Reinstate error IRQ Pentium erratum 3AP workaround · 023de4a0
      Maciej W. Rozycki 提交于
      A change introduced with commit 60283df7
      ("x86/apic: Read Error Status Register correctly") removed a read from the
      APIC ESR register made before writing to same required to retrieve the
      correct error status on Pentium systems affected by the 3AP erratum[1]:
      
      	"3AP. Writes to Error Register Clears Register
      
      	PROBLEM: The APIC Error register is intended to only be read.
      	If there is a write to this register the data in the APIC Error
      	register will be cleared and lost.
      
      	IMPLICATION: There is a possibility of clearing the Error
      	register status since the write to the register is not
      	specifically blocked.
      
      	WORKAROUND: Writes should not occur to the Pentium processor
      	APIC Error register.
      
      	STATUS: For the steppings affected see the Summary Table of
      	Changes at the beginning of this section."
      
      The steppings affected are actually: B1, B3 and B5.
      
      To avoid this information loss this change avoids the write to
      ESR on all Pentium systems where it is actually never needed;
      in Pentium processor documentation ESR was noted read-only and
      the write only required for future architectural
      compatibility[2].
      
      The approach taken is the same as in lapic_setup_esr().
      
      References:
      
      	[1] "Pentium Processor Family Developer's Manual", Intel Corporation,
      	    1997, order number 241428-005, Appendix A "Errata and S-Specs for the
      	    Pentium Processor Family", p. A-92,
      
      	[2] "Pentium Processor Family Developer's Manual, Volume 3: Architecture
      	    and Programming Manual", Intel Corporation, 1995, order number
      	    241430-004, Section 19.3.3. "Error Handling In APIC", p. 19-33.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Cc: Richard Weinberger <richard@nod.at>
      Link: http://lkml.kernel.org/r/alpine.LFD.2.11.1404011300010.27402@eddie.linux-mips.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      023de4a0
  9. 11 3月, 2014 1 次提交
  10. 28 2月, 2014 1 次提交
  11. 09 2月, 2014 1 次提交
  12. 16 1月, 2014 2 次提交
    • H
      x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos · 5b4d1dbc
      H. Peter Anvin 提交于
      Make disabled_cpu_apicid static and read_mostly, and fix a couple of
      typos.
      Reported-by: NIngo Molnar <mingo@kernel.org>
      Link: http://lkml.kernel.org/r/20140115182511.GA22737@gmail.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      5b4d1dbc
    • H
      x86, apic, kexec: Add disable_cpu_apicid kernel parameter · 151e0c7d
      HATAYAMA Daisuke 提交于
      Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
      specify an initial APIC ID of the corresponding CPU you want to
      disable.
      
      This is mostly used for the kdump 2nd kernel to disable BSP to wake up
      multiple CPUs without causing system reset or hang due to sending INIT
      from AP to BSP.
      
      Kdump users first figure out initial APIC ID of the BSP, CPU0 in the
      1st kernel, for example from /proc/cpuinfo and then set up this kernel
      parameter for the 2nd kernel using the obtained APIC ID.
      
      However, doing this procedure at each boot time manually is awkward,
      which should be automatically done by user-land service scripts, for
      example, kexec-tools on fedora/RHEL distributions.
      
      This design is more flexible than disabling BSP in kernel boot time
      automatically in that in kernel boot time we have no choice but
      referring to ACPI/MP table to obtain initial APIC ID for BSP, meaning
      that the method is not applicable to the systems without such BIOS
      tables.
      
      One assumption behind this design is that users get initial APIC ID of
      the BSP in still healthy state and so BSP is uniquely kept in
      CPU0. Thus, through the kernel parameter, only one initial APIC ID can
      be specified.
      
      In a comparison with disabled_cpu_apicid, we use read_apic_id(), not
      boot_cpu_physical_apicid, because on some platforms, the variable is
      modified to the apicid reported as BSP through MP table and this
      function is executed with the temporarily modified
      boot_cpu_physical_apicid. As a result, disabled_cpu_apicid kernel
      parameter doesn't work well for apicids of APs.
      
      Fixing the wrong handling of boot_cpu_physical_apicid requires some
      reviews and tests beyond some platforms and it could take some
      time. The fix here is a kind of workaround to focus on the main topic
      of this patch.
      Signed-off-by: NHATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Link: http://lkml.kernel.org/r/20140115064458.1545.38775.stgit@localhost6.localdomain6Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      151e0c7d
  13. 14 1月, 2014 1 次提交
    • R
      x86/apic: Read Error Status Register correctly · 60283df7
      Richard Weinberger 提交于
      Currently we do a read, a dummy write and a final read to fetch
      the error code. The value from the final read is taken.
      This is not the recommended way and leads to corrupted/lost ESR
      values.
      
      Intel(c) 64 and IA-32 Architectures Software Developer's Manual,
      Combined Volumes 1, 2ABC, 3ABC, Section 10.5.3 states:
      
        Before attempt to read from the ESR, software should first
        write to it. (The value written does not affect the values read
        subsequently; only zero may be written in x2APIC mode.) This
        write clears any previously logged errors and updates the ESR
        with any errors detected since the last write to the ESR.
        This write also rearms the APIC error interrupt triggering
        mechanism.
      
      This patch removes the first read such that we are conform with
      the manual.
      
      On my (very old) Pentium MMX SMP system this patch fixes the
      issue that APIC errors:
      
        a) are not always reported and
        b) are reported with false error numbers.
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      Cc: seiji.aguchi@hds.com
      Cc: rientjes@google.com
      Cc: konrad.wilk@oracle.com
      Cc: bp@alien8.de
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1389685487-20872-1-git-send-email-richard@nod.atSigned-off-by: NIngo Molnar <mingo@kernel.org>
      60283df7
  14. 15 11月, 2013 1 次提交
  15. 24 9月, 2013 1 次提交
  16. 07 8月, 2013 1 次提交
  17. 15 7月, 2013 1 次提交
    • P
      x86: delete __cpuinit usage from all x86 files · 148f9bb8
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      content into no-ops as early as possible, since that will get rid
      of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the arch/x86 uses of the __cpuinit macros from
      all C files.  x86 only had the one __CPUINIT used in assembly files,
      and it wasn't paired off with a .previous or a __FINIT, so we can
      delete it directly w/o any corresponding additional change there.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      148f9bb8
  18. 21 6月, 2013 3 次提交
    • S
      trace,x86: Move creation of irq tracepoints from apic.c to irq.c · 83ab8514
      Steven Rostedt (Red Hat) 提交于
      Compiling without CONFIG_X86_LOCAL_APIC set, apic.c will not be
      compiled, and the irq tracepoints will not be created via the
      CREATE_TRACE_POINTS macro. When CONFIG_X86_LOCAL_APIC is not set,
      we get the following build error:
      
        LD      init/built-in.o
      arch/x86/built-in.o: In function `trace_x86_platform_ipi_entry':
      linux-test.git/arch/x86/include/asm/trace/irq_vectors.h:66: undefined reference to `__tracepoint_x86_platform_ipi_entry'
      arch/x86/built-in.o: In function `trace_x86_platform_ipi_exit':
      linux-test.git/arch/x86/include/asm/trace/irq_vectors.h:66: undefined reference to `__tracepoint_x86_platform_ipi_exit'
      arch/x86/built-in.o: In function `trace_irq_work_entry':
      linux-test.git/arch/x86/include/asm/trace/irq_vectors.h:72: undefined reference to `__tracepoint_irq_work_entry'
      arch/x86/built-in.o: In function `trace_irq_work_exit':
      linux-test.git/arch/x86/include/asm/trace/irq_vectors.h:72: undefined reference to `__tracepoint_irq_work_exit'
      arch/x86/built-in.o:(__jump_table+0x8): undefined reference to `__tracepoint_x86_platform_ipi_entry'
      arch/x86/built-in.o:(__jump_table+0x14): undefined reference to `__tracepoint_x86_platform_ipi_exit'
      arch/x86/built-in.o:(__jump_table+0x20): undefined reference to `__tracepoint_irq_work_entry'
      arch/x86/built-in.o:(__jump_table+0x2c): undefined reference to `__tracepoint_irq_work_exit'
      make[1]: *** [vmlinux] Error 1
      make: *** [sub-make] Error 2
      
      As irq.c is always compiled for x86, it is a more appropriate location
      to create the irq tracepoints.
      
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      83ab8514
    • S
      x86, trace: Add irq vector tracepoints · cf910e83
      Seiji Aguchi 提交于
      [Purpose of this patch]
      
      As Vaibhav explained in the thread below, tracepoints for irq vectors
      are useful.
      
      http://www.spinics.net/lists/mm-commits/msg85707.html
      
      <snip>
      The current interrupt traces from irq_handler_entry and irq_handler_exit
      provide when an interrupt is handled.  They provide good data about when
      the system has switched to kernel space and how it affects the currently
      running processes.
      
      There are some IRQ vectors which trigger the system into kernel space,
      which are not handled in generic IRQ handlers.  Tracing such events gives
      us the information about IRQ interaction with other system events.
      
      The trace also tells where the system is spending its time.  We want to
      know which cores are handling interrupts and how they are affecting other
      processes in the system.  Also, the trace provides information about when
      the cores are idle and which interrupts are changing that state.
      <snip>
      
      On the other hand, my usecase is tracing just local timer event and
      getting a value of instruction pointer.
      
      I suggested to add an argument local timer event to get instruction pointer before.
      But there is another way to get it with external module like systemtap.
      So, I don't need to add any argument to irq vector tracepoints now.
      
      [Patch Description]
      
      Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all events.
      But there is an above use case to trace specific irq_vector rather than tracing all events.
      In this case, we are concerned about overhead due to unwanted events.
      
      So, add following tracepoints instead of introducing irq_vector_entry/exit.
      so that we can enable them independently.
         - local_timer_vector
         - reschedule_vector
         - call_function_vector
         - call_function_single_vector
         - irq_work_entry_vector
         - error_apic_vector
         - thermal_apic_vector
         - threshold_apic_vector
         - spurious_apic_vector
         - x86_platform_ipi_vector
      
      Also, introduce a logic switching IDT at enabling/disabling time so that a time penalty
      makes a zero when tracepoints are disabled. Detailed explanations are as follows.
       - Create trace irq handlers with entering_irq()/exiting_irq().
       - Create a new IDT, trace_idt_table, at boot time by adding a logic to
         _set_gate(). It is just a copy of original idt table.
       - Register the new handlers for tracpoints to the new IDT by introducing
         macros to alloc_intr_gate() called at registering time of irq_vector handlers.
       - Add checking, whether irq vector tracing is on/off, into load_current_idt().
         This has to be done below debug checking for these reasons.
         - Switching to debug IDT may be kicked while tracing is enabled.
         - On the other hands, switching to trace IDT is kicked only when debugging
           is disabled.
      
      In addition, the new IDT is created only when CONFIG_TRACING is enabled to avoid being
      used for other purposes.
      Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Link: http://lkml.kernel.org/r/51C323ED.5050708@hds.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      cf910e83
    • S
      x86, trace: Introduce entering/exiting_irq() · eddc0e92
      Seiji Aguchi 提交于
      When implementing tracepoints in interrupt handers, if the tracepoints are
      simply added in the performance sensitive path of interrupt handers,
      it may cause potential performance problem due to the time penalty.
      
      To solve the problem, an idea is to prepare non-trace/trace irq handers and
      switch their IDTs at the enabling/disabling time.
      
      So, let's introduce entering_irq()/exiting_irq() for pre/post-
      processing of each irq handler.
      
      A way to use them is as follows.
      
      Non-trace irq handler:
      smp_irq_handler()
      {
      	entering_irq();		/* pre-processing of this handler */
      	__smp_irq_handler();	/*
      				 * common logic between non-trace and trace handlers
      				 * in a vector.
      				 */
      	exiting_irq();		/* post-processing of this handler */
      
      }
      
      Trace irq_handler:
      smp_trace_irq_handler()
      {
      	entering_irq();		/* pre-processing of this handler */
      	trace_irq_entry();	/* tracepoint for irq entry */
      	__smp_irq_handler();	/*
      				 * common logic between non-trace and trace handlers
      				 * in a vector.
      				 */
      	trace_irq_exit();	/* tracepoint for irq exit */
      	exiting_irq();		/* post-processing of this handler */
      
      }
      
      If tracepoints can place outside entering_irq()/exiting_irq() as follows,
      it looks cleaner.
      
      smp_trace_irq_handler()
      {
      	trace_irq_entry();
      	smp_irq_handler();
      	trace_irq_exit();
      }
      
      But it doesn't work.
      The problem is with irq_enter/exit() being called. They must be called before
      trace_irq_enter/exit(),  because of the rcu_irq_enter() must be called before
      any tracepoints are used, as tracepoints use  rcu to synchronize.
      
      As a possible alternative, we may be able to call irq_enter() first as follows
      if irq_enter() can nest.
      
      smp_trace_irq_hander()
      {
      	irq_entry();
      	trace_irq_entry();
      	smp_irq_handler();
      	trace_irq_exit();
      	irq_exit();
      }
      
      But it doesn't work, either.
      If irq_enter() is nested, it may have a time penalty because it has to check if it
      was already called or not. The time penalty is not desired in performance sensitive
      paths even if it is tiny.
      Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Link: http://lkml.kernel.org/r/51C3238D.9040706@hds.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      eddc0e92
  19. 31 5月, 2013 1 次提交
  20. 20 2月, 2013 1 次提交
  21. 28 1月, 2013 2 次提交
  22. 02 11月, 2012 1 次提交
  23. 19 9月, 2012 1 次提交
  24. 16 7月, 2012 1 次提交
  25. 14 6月, 2012 3 次提交
  26. 08 6月, 2012 2 次提交
    • A
      x86/apic: Make cpu_mask_to_apicid() operations check cpu_online_mask · 4988a40c
      Alexander Gordeev 提交于
      Currently cpu_mask_to_apicid() should not get a offline CPU with
      the cpumask. Otherwise some apic drivers might try to access
      non-existent per-cpu variables (i.e. x2apic). In that regard
      cpu_mask_to_apicid() and cpu_mask_to_apicid_and() operations are
      inconsistent.
      
      This fix makes the two operations do not rely on calling
      functions and always return the apicid for only online CPUs. As
      result, the meaning and implementations of cpu_mask_to_apicid()
      and cpu_mask_to_apicid_and() operations become straight.
      Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/20120607131624.GG4759@dhcp-26-207.brq.redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      4988a40c
    • A
      x86/apic: Make cpu_mask_to_apicid() operations return error code · ff164324
      Alexander Gordeev 提交于
      Current cpu_mask_to_apicid() and cpu_mask_to_apicid_and()
      implementations have few shortcomings:
      
      1. A value returned by cpu_mask_to_apicid() is written to
      hardware registers unconditionally. Should BAD_APICID get ever
      returned it will be written to a hardware too. But the value of
      BAD_APICID is not universal across all hardware in all modes and
      might cause unexpected results, i.e. interrupts might get routed
      to CPUs that are not configured to receive it.
      
      2. Because the value of BAD_APICID is not universal it is
      counter- intuitive to return it for a hardware where it does not
      make sense (i.e. x2apic).
      
      3. cpu_mask_to_apicid_and() operation is thought as an
      complement to cpu_mask_to_apicid() that only applies a AND mask
      on top of a cpumask being passed. Yet, as consequence of 18374d89
      commit the two operations are inconsistent in that of:
        cpu_mask_to_apicid() should not get a offline CPU with the cpumask
        cpu_mask_to_apicid_and() should not fail and return BAD_APICID
      These limitations are impossible to realize just from looking at
      the operations prototypes.
      
      Most of these shortcomings are resolved by returning a error
      code instead of BAD_APICID. As the result, faults are reported
      back early rather than possibilities to cause a unexpected
      behaviour exist (in case of [1]).
      
      The only exception is setup_timer_IRQ0_pin() routine. Although
      obviously controversial to this fix, its existing behaviour is
      preserved to not break the fragile check_timer() and would
      better addressed in a separate fix.
      Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/20120607131559.GF4759@dhcp-26-207.brq.redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ff164324
  27. 06 6月, 2012 1 次提交