1. 28 1月, 2011 1 次提交
    • T
      x86: Kill apic->cpu_to_logical_apicid() · 7632611f
      Tejun Heo 提交于
      After the previous patch, apic->cpu_to_logical_apicid() is no
      longer used.  Kill it.
      
      For apic types with custom cpu_to_logical_apicid() which is also
      used for other purposes, remove the function and modify its
      users to do the mapping directly.
      
      #ifdef's on CONFIG_SMP in es7000_32 and summit_32 are ignored
      during conversion as they are not used for UP kernels.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: eric.dumazet@gmail.com
      Cc: yinghai@kernel.org
      Cc: brgerst@gmail.com
      Cc: gorcunov@gmail.com
      Cc: penberg@kernel.org
      Cc: shaohui.zheng@intel.com
      Cc: rientjes@google.com
      LKML-Reference: <1295789862-25482-7-git-send-email-tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7632611f
  2. 18 12月, 2009 1 次提交
    • S
      x86, irq: Allow 0xff for /proc/irq/[n]/smp_affinity on an 8-cpu system · 18374d89
      Suresh Siddha 提交于
      John Blackwood reported:
      > on an older Dell PowerEdge 6650 system with 8 cpus (4 are hyper-threaded),
      > and  32 bit (x86) kernel, once you change the irq smp_affinity of an irq
      > to be less than all cpus in the system, you can never change really the
      > irq smp_affinity back to be all cpus in the system (0xff) again,
      > even though no error status is returned on the "/bin/echo ff >
      > /proc/irq/[n]/smp_affinity" operation.
      >
      > This is due to that fact that BAD_APICID has the same value as
      > all cpus (0xff) on 32bit kernels, and thus the value returned from
      > set_desc_affinity() via the cpu_mask_to_apicid_and() function is treated
      > as a failure in set_ioapic_affinity_irq_desc(), and no affinity changes
      > are made.
      
      set_desc_affinity() is already checking if the incoming cpu mask
      intersects with the cpu online mask or not. So there is no need
      for the apic op cpu_mask_to_apicid_and() to check again
      and return BAD_APICID.
      
      Remove the BAD_APICID return value from cpu_mask_to_apicid_and()
      and also fix set_desc_affinity() to return -1 instead of using BAD_APICID
      to represent error conditions (as cpu_mask_to_apicid_and() can return
      logical or physical apicid values and BAD_APICID is really to represent
      bad physical apic id).
      Reported-by: NJohn Blackwood <john.blackwood@ccur.com>
      Root-caused-by: NJohn Blackwood <john.blackwood@ccur.com>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <1261103386.2535.409.camel@sbs-t61>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      18374d89
  3. 08 8月, 2009 1 次提交
    • Y
      x86: Fix MSI-X initialization by using online_mask for x2apic target_cpus · 087d7e56
      Yinghai Lu 提交于
      found a system where x2apic reports an MSI-X irq initialization
      failure:
      
      [  302.859446] igbvf 0000:81:10.4: enabling device (0000 -> 0002)
      [  302.874369] igbvf 0000:81:10.4: using 64bit DMA mask
      [  302.879023] igbvf 0000:81:10.4: using 64bit consistent DMA mask
      [  302.894386] igbvf 0000:81:10.4: enabling bus mastering
      [  302.898171] igbvf 0000:81:10.4: setting latency timer to 64
      [  302.914050] reserve_memtype added 0xefb08000-0xefb0c000, track uncached-minus, req uncached-minus, ret uncached-minus
      [  302.933839] reserve_memtype added 0xefb28000-0xefb29000, track uncached-minus, req uncached-minus, ret uncached-minus
      [  302.940367]   alloc irq_desc for 265 on node 4
      [  302.956874]   alloc kstat_irqs on node 4
      [  302.959452] alloc irq_2_iommu on node 0
      [  302.974328] igbvf 0000:81:10.4: irq 265 for MSI/MSI-X
      [  302.977778]   alloc irq_desc for 266 on node 4
      [  302.980347]   alloc kstat_irqs on node 4
      [  302.995312] free_memtype request 0xefb28000-0xefb29000
      [  302.998816] igbvf 0000:81:10.4: Failed to initialize MSI-X interrupts.
      
      ... it turns out that when trying to enable MSI-X,
      __assign_irq_vector(new, cfg_new, apic->target_cpus()) can not
      get vector because for x2apic target-cpus returns cpumask_of(0)
      
      Update that to online_mask like xapic.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <4A785AFF.3050902@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      087d7e56
  4. 04 8月, 2009 1 次提交
    • Y
      x86: Don't use current_cpu_data in x2apic phys_pkg_id · d8c7eb34
      Yinghai Lu 提交于
      One system has socket 1 come up as BSP.
      
      kexeced kernel reports BSP as:
      
      [    1.524550] Initializing cgroup subsys cpuacct
      [    1.536064] initial_apicid:20
      [    1.537135] ht_mask_width:1
      [    1.538128] core_select_mask:f
      [    1.539126] core_plus_mask_width:5
      [    1.558479] CPU: Physical Processor ID: 0
      [    1.559501] CPU: Processor Core ID: 0
      [    1.560539] CPU: L1 I cache: 32K, L1 D cache: 32K
      [    1.579098] CPU: L2 cache: 256K
      [    1.580085] CPU: L3 cache: 24576K
      [    1.581108] CPU 0/0x20 -> Node 0
      [    1.596193] CPU 0 microcode level: 0xffff0008
      
      It doesn't have correct physical processor id and will get an
      error:
      
      [   38.840859] CPU0 attaching sched-domain:
      [   38.848287]  domain 0: span 0,8,72 level SIBLING
      [   38.851151]   groups: 0 8 72
      [   38.858137]   domain 1: span 0,8-15,72-79 level MC
      [   38.868944]    groups: 0,8,72 9,73 10,74 11,75 12,76 13,77 14,78 15,79
      [   38.881383] ERROR: parent span is not a superset of domain->span
      [   38.890724]    domain 2: span 0-7,64-71 level CPU
      [   38.899237] ERROR: domain->groups does not contain CPU0
      [   38.909229]     groups: 8-15,72-79
      [   38.912547] ERROR: groups don't span domain->span
      [   38.919665]     domain 3: span 0-127 level NODE
      [   38.930739]      groups: 0-7,64-71 8-15,72-79 16-23,80-87 24-31,88-95 32-39,96-103 40-47,104-111 48-55,112-119 56-63,120-127
      
      it turns out: we can not use current_cpu_data in phys_pgd_id
      for x2apic.
      
      identify_boot_cpu() is called by check_bugs() before
      smp_prepare_cpus() and till smp_prepare_cpus() current_cpu_data
      for bsp is assigned with boot_cpu_data.
      
      Just make phys_pkg_id for x2apic is aligned to xapic.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <4A6ADD0D.10002@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d8c7eb34
  5. 18 3月, 2009 1 次提交
    • S
      x86: add x2apic_wrmsr_fence() to x2apic flush tlb paths · ce4e240c
      Suresh Siddha 提交于
      Impact: optimize APIC IPI related barriers
      
      Uncached MMIO accesses for xapic are inherently serializing and hence
      we don't need explicit barriers for xapic IPI paths.
      
      x2apic MSR writes/reads don't have serializing semantics and hence need
      a serializing instruction or mfence, to make all the previous memory
      stores globally visisble before the x2apic msr write for IPI.
      
      Add x2apic_wrmsr_fence() in flush tlb path to x2apic specific paths.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "steiner@sgi.com" <steiner@sgi.com>
      Cc: Nick Piggin <npiggin@suse.de>
      LKML-Reference: <1237313814.27006.203.camel@localhost.localdomain>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ce4e240c
  6. 26 2月, 2009 2 次提交
  7. 23 2月, 2009 1 次提交
  8. 18 2月, 2009 4 次提交
  9. 17 2月, 2009 1 次提交
  10. 29 1月, 2009 14 次提交
  11. 30 12月, 2008 1 次提交
  12. 18 12月, 2008 1 次提交
    • M
      x86: fix cpu_mask_to_apicid_and to include cpu_online_mask · a775a38b
      Mike Travis 提交于
      Impact: fix potential APIC crash
      
      In determining the destination apicid, there are usually three cpumasks
      that are considered: the incoming cpumask arg, cfg->domain and the
      cpu_online_mask.  Since we are just introducing the cpu_mask_to_apicid_and
      function, make sure it includes the cpu_online_mask in it's evaluation.
      [Added with this patch.]
      
      There are two io_apic.c functions that did not previously use the
      cpu_online_mask:  setup_IO_APIC_irq and msi_compose_msg.  Both of these
      simply used cpu_mask_to_apicid(cfg->domain & TARGET_CPUS), and all but
      one arch (NUMAQ[*]) returns only online cpus in the TARGET_CPUS mask,
      so the behavior is identical for all cases.
      
      [*: NUMAQ bug?]
      
      Note that alloc_cpumask_var is only used for the 32-bit cases where
      it's highly likely that the cpumask set size will be small and therefore
      CPUMASK_OFFSTACK=n.  But if that's not the case, failing the allocate
      will cause the same return value as the default.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a775a38b
  13. 17 12月, 2008 4 次提交
  14. 22 10月, 2008 1 次提交
  15. 23 8月, 2008 1 次提交
    • S
      x86: use x2apic id reported by cpuid during topology discovery · e17941b0
      Suresh Siddha 提交于
      use x2apic id reported by cpuid during topology discovery, instead of the
      apic id configured in the APIC. For most of the systems, x2apic id
      reported by cpuid leaf 0xb will be same as the physical apic id reported
      by the APIC_ID register of the APIC. We follow the suggested guidelines
      and use the apic id reported by the cpuid.
      
      No change to non-generic UV platforms, will use the apic id reported in the
      APIC_ID register as the cpuid reported apic id's may not be unique.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e17941b0
  16. 27 7月, 2008 1 次提交
  17. 24 7月, 2008 1 次提交
  18. 22 7月, 2008 1 次提交
    • Y
      x86: add apic probe for genapic 64bit, v2 · 1b9b89e7
      Yinghai Lu 提交于
      introducing an APIC handling probing abstraction:
      
       static struct genapic *apic_probe[] __initdata = {
      	&apic_x2apic_uv_x,
      	&apic_x2apic_phys,
      	&apic_x2apic_cluster,
      	&apic_physflat,
      	NULL,
       };
      
      This way we can remove UV, x2apic specific code from genapic_64.c and
      move them to their specific genapic files.
      
      [ v2: fix compiling when CONFIG_ACPI is not set ]
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Jack Steiner <steiner@sgi.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1b9b89e7
  19. 13 7月, 2008 1 次提交
    • Y
      x86: make 64bit have get_apic_id · f910a9dc
      Yinghai Lu 提交于
      generalize the x2apic code some more.
      
      let read_apic_id become a macro (later on a function/inline)
      GET_APIC_ID(apic_read(APIC_ID))
      
        +#define read_apic_id()  (GET_APIC_ID(apic_read(APIC_ID)))
      
      instead of this weird construct:
      
        -#define read_apic_id  (genapic->read_apic_id)
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f910a9dc
  20. 12 7月, 2008 1 次提交