1. 24 11月, 2015 1 次提交
  2. 01 10月, 2015 1 次提交
  3. 15 9月, 2015 1 次提交
    • S
      x86/apic: Serialize LVTT and TSC_DEADLINE writes · 5d7c631d
      Shaohua Li 提交于
      The APIC LVTT register is MMIO mapped but the TSC_DEADLINE register is an
      MSR. The write to the TSC_DEADLINE MSR is not serializing, so it's not
      guaranteed that the write to LVTT has reached the APIC before the
      TSC_DEADLINE MSR is written. In such a case the write to the MSR is
      ignored and as a consequence the local timer interrupt never fires.
      
      The SDM decribes this issue for xAPIC and x2APIC modes. The
      serialization methods recommended by the SDM differ.
      
      xAPIC:
       "1. Memory-mapped write to LVT Timer Register, setting bits 18:17 to 10b.
        2. WRMSR to the IA32_TSC_DEADLINE MSR a value much larger than current time-stamp counter.
        3. If RDMSR of the IA32_TSC_DEADLINE MSR returns zero, go to step 2.
        4. WRMSR to the IA32_TSC_DEADLINE MSR the desired deadline."
      
      x2APIC:
       "To allow for efficient access to the APIC registers in x2APIC mode,
        the serializing semantics of WRMSR are relaxed when writing to the
        APIC registers. Thus, system software should not use 'WRMSR to APIC
        registers in x2APIC mode' as a serializing instruction. Read and write
        accesses to the APIC registers will occur in program order. A WRMSR to
        an APIC register may complete before all preceding stores are globally
        visible; software can prevent this by inserting a serializing
        instruction, an SFENCE, or an MFENCE before the WRMSR."
      
      The xAPIC method is to just wait for the memory mapped write to hit
      the LVTT by checking whether the MSR write has reached the hardware.
      There is no reason why a proper MFENCE after the memory mapped write would
      not do the same. Andi Kleen confirmed that MFENCE is sufficient for the
      xAPIC case as well.
      
      Issue MFENCE before writing to the TSC_DEADLINE MSR. This can be done
      unconditionally as all CPUs which have TSC_DEADLINE also have MFENCE
      support.
      
      [ tglx: Massaged the changelog ]
      Signed-off-by: NShaohua Li <shli@fb.com>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: <Kernel-team@fb.com>
      Cc: <lenb@kernel.org>
      Cc: <fenghua.yu@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: stable@vger.kernel.org #v3.7+
      Link: http://lkml.kernel.org/r/20150909041352.GA2059853@devbig257.prn2.facebook.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      5d7c631d
  4. 22 8月, 2015 1 次提交
    • T
      x86/apic: Fix fallout from x2apic cleanup · a57e456a
      Thomas Gleixner 提交于
      In the recent x2apic cleanup I got two things really wrong:
      1) The safety check in __disable_x2apic which allows the function to
         be called unconditionally is backwards. The check is there to
         prevent access to the apic MSR in case that the machine has no
         apic. Though right now it returns if the machine has an apic and
         therefor the disabling of x2apic is never invoked.
      
      2) x2apic_disable() sets x2apic_mode to 0 after registering the local
         apic. That's wrong, because register_lapic_address() checks x2apic
         mode and therefor takes the wrong code path.
      
      This results in boot failures on machines with x2apic preenabled by
      BIOS and can also lead to an fatal MSR access on machines without
      apic.
      
      The solutions are simple:
      1) Correct the sanity check for apic availability
      2) Clear x2apic_mode _before_ calling register_lapic_address()
      
      Fixes: 659006bf 'x86/x2apic: Split enable and setup function'
      Reported-and-tested-by: NJavier Monteagudo <javiermon@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1224764
      Cc: stable@vger.kernel.org # 4.0+
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      a57e456a
  5. 30 7月, 2015 2 次提交
  6. 06 7月, 2015 2 次提交
  7. 01 4月, 2015 1 次提交
  8. 14 2月, 2015 1 次提交
  9. 22 1月, 2015 18 次提交
  10. 15 1月, 2015 9 次提交
    • J
      iommu/irq_remapping: Kill function irq_remapping_supported() and related code · c392f56c
      Jiang Liu 提交于
      Simplify irq_remapping code by killing irq_remapping_supported() and
      related interfaces.
      
      Joerg posted a similar patch at https://lkml.org/lkml/2014/12/15/490,
      so assume an signed-off from Joerg.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Tested-by: NJoerg Roedel <joro@8bytes.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      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-14-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      c392f56c
    • J
      x86/apic: Only disable CPU x2apic mode when necessary · 5fcee53c
      Jiang Liu 提交于
      When interrupt remapping hardware is not in X2APIC, CPU X2APIC mode
      will be disabled if:
      1) Maximum CPU APIC ID is bigger than 255
      2) hypervisior doesn't support x2apic mode.
      
      But we should only check whether hypervisor supports X2APIC mode when
      hypervisor(CONFIG_HYPERVISOR_GUEST) is enabled, otherwise X2APIC will
      always be disabled when CONFIG_HYPERVISOR_GUEST is disabled and IR
      doesn't work in X2APIC mode.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Tested-by: NJoerg Roedel <joro@8bytes.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      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-12-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      5fcee53c
    • J
      x86/apic: Handle XAPIC remap mode proper. · ef1b2b8a
      Jiang Liu 提交于
      If remapping is in XAPIC mode, the setup code just skips X2APIC
      initialization without checking max CPU APIC ID in system, which may
      cause problem if system has a CPU with APIC ID bigger than 255.
      
      Handle IR in XAPIC mode the same way as if remapping is disabled.
      
      [ tglx: Split out from previous patch ]
      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>
      ef1b2b8a
    • 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
  11. 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
  12. 23 10月, 2014 1 次提交
  13. 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