1. 18 5月, 2012 2 次提交
  2. 25 4月, 2012 1 次提交
  3. 23 3月, 2012 1 次提交
    • S
      x86/apic: Add separate apic_id_valid() functions for selected apic drivers · b7157acf
      Steffen Persvold 提交于
      As suggested by Suresh Siddha and Yinghai Lu:
      
      For x2apic pre-enabled systems, apic driver is set already early
      through early_acpi_boot_init()/early_acpi_process_madt()/
      acpi_parse_madt()/default_acpi_madt_oem_check() path so that
      apic_id_valid() checking will be sufficient during MADT and SRAT
      parsing.
      
      For non-x2apic pre-enabled systems, all apic ids should be less
      than 255.
      
      This allows us to substitute the checks in
      arch/x86/kernel/acpi/boot.c::acpi_parse_x2apic() and
      arch/x86/mm/srat.c::acpi_numa_x2apic_affinity_init() with
      apic->apic_id_valid().
      
      In addition we can avoid feigning the x2apic cpu feature in the
      NumaChip apic code.
      
      The following apic drivers have separate apic_id_valid()
      functions which will accept x2apic type IDs :
      
       x2apic_phys
       x2apic_cluster
       x2apic_uv_x
       apic_numachip
      Signed-off-by: NSteffen Persvold <sp@numascale.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Daniel J Blueman <daniel@numascale-asia.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Jack Steiner <steiner@sgi.com>
      Link: http://lkml.kernel.org/r/1331925935-13372-1-git-send-email-sp@numascale.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b7157acf
  4. 14 3月, 2012 1 次提交
  5. 22 5月, 2011 2 次提交
  6. 20 5月, 2011 3 次提交
  7. 28 1月, 2011 2 次提交
    • T
      x86: Replace apic->apicid_to_node() with ->x86_32_numa_cpu_node() · 89e5dc21
      Tejun Heo 提交于
      apic->apicid_to_node() is 32bit specific apic operation which
      determines NUMA node for a CPU.  Depending on the APIC
      implementation, it can be easier to determine NUMA node from
      either physical or logical apicid.  Currently,
      ->apicid_to_node() takes @logical_apicid and calls
      hard_smp_processor_id() if the physical apicid is needed.
      
      This prevents NUMA mapping from being queried from a different
      CPU, which in turn makes it impossible to initialize NUMA
      mapping before SMP bringup.
      
      This patch replaces apic->apicid_to_node() with
      ->x86_32_numa_cpu_node() which takes @cpu, from which both
      logical and physical apicids can easily be determined.  While at
      it, drop duplicate implementations from bigsmp_32 and summit_32,
      and use the default one.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NPekka Enberg <penberg@kernel.org>
      Cc: eric.dumazet@gmail.com
      Cc: yinghai@kernel.org
      Cc: brgerst@gmail.com
      Cc: gorcunov@gmail.com
      Cc: shaohui.zheng@intel.com
      Cc: rientjes@google.com
      LKML-Reference: <1295789862-25482-13-git-send-email-tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      89e5dc21
    • 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 26 2月, 2009 2 次提交
  13. 23 2月, 2009 1 次提交
  14. 18 2月, 2009 4 次提交
  15. 17 2月, 2009 1 次提交
  16. 29 1月, 2009 14 次提交
  17. 30 12月, 2008 1 次提交
  18. 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