1. 10 Nov, 2009 1 commit
    • Cyrill Gorcunov's avatar
      x86: apic: Do not use stacked physid_mask_t · 7abc0753
      Cyrill Gorcunov authored
      We should not use physid_mask_t as a stack based
      variable in apic code. This type depends on MAX_APICS
      parameter which may be huge enough.
      
      Especially it became a problem with apic NOOP driver which
      is portable between 32 bit and 64 bit environment
      (where we have really huge MAX_APICS).
      
      So apic driver should operate with pointers and a caller
      in turn should aware of allocation physid_mask_t variable.
      
      As a side (but positive) effect -- we may use already
      implemented physid_set_mask_of_physid function eliminating
      default_apicid_to_cpu_present completely.
      
      Note that physids_coerce and physids_promote turned into static
      inline from macro (since macro hides the fact that parameter is
      being interpreted as unsigned long, make it explicit).
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      LKML-Reference: <20091109220659.GA5568@lenovo>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7abc0753
  2. 08 Nov, 2009 3 commits
  3. 02 Nov, 2009 6 commits
    • Suresh Siddha's avatar
      x86: Remove local_irq_enable()/local_irq_disable() in fixup_irqs() · 5231a686
      Suresh Siddha authored
      To ensure that we handle all the pending interrupts (destined
      for this cpu that is going down) in the interrupt subsystem
      before the cpu goes offline, fixup_irqs() does:
      
      	local_irq_enable();
      	mdelay(1);
      	local_irq_disable();
      
      Enabling interrupts is not a good thing as this cpu is already
      offline. So this patch replaces that logic with,
      
      	mdelay(1);
      	check APIC_IRR bits
      	Retrigger the irq at the new destination if any interrupt has arrived
      	via IPI.
      
      For IO-APIC level triggered interrupts, this retrigger IPI will
      appear as an edge interrupt. ack_apic_level() will detect this
      condition and IO-APIC RTE's remoteIRR is cleared using directed
      EOI(using IO-APIC EOI register) on Intel platforms and for
      others it uses the existing mask+edge logic followed by
      unmask+level.
      
      We can also remove mdelay() and then send spuriuous interrupts
      to new cpu targets for all the irqs that were handled previously
      by this cpu that is going offline. While it works, I have seen
      spurious interrupt messages (nothing wrong but still annoying
      messages during cpu offline, which can be seen during
      suspend/resume etc)
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: default avatarGary Hade <garyhade@us.ibm.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <20091026230002.043281924@sbs-t61.sc.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5231a686
    • Suresh Siddha's avatar
      x86: Use EOI register in io-apic on intel platforms · b3ec0a37
      Suresh Siddha authored
      IO-APIC's in intel chipsets support EOI register starting from
      IO-APIC version 2. Use that when ever we need to clear the
      IO-APIC RTE's RemoteIRR bit explicitly.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: default avatarGary Hade <garyhade@us.ibm.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <20091026230001.947855317@sbs-t61.sc.intel.com>
      [ Marked use_eio_reg as __read_mostly, fixed small details ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b3ec0a37
    • Suresh Siddha's avatar
      x86: Force irq complete move during cpu offline · a5e74b84
      Suresh Siddha authored
      When a cpu goes offline, fixup_irqs() try to move irq's
      currently destined to the offline cpu to a new cpu. But this
      attempt will fail if the irq is recently moved to this cpu and
      the irq still hasn't arrived at this cpu (for non intr-remapping
      platforms this is when we free the vector allocation at the
      previous destination) that is about to go offline.
      
      This will endup with the interrupt subsystem still pointing the
      irq to the offline cpu, causing that irq to not work any more.
      
      Fix this by forcing the irq to complete its move (its been a
      long time we moved the irq to this cpu which we are offlining
      now) and then move this irq to a new cpu before this cpu goes
      offline.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: default avatarGary Hade <garyhade@us.ibm.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <20091026230001.848830905@sbs-t61.sc.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a5e74b84
    • Suresh Siddha's avatar
      x86: Remove move_cleanup_count from irq_cfg · 23359a88
      Suresh Siddha authored
      move_cleanup_count for each irq in irq_cfg is keeping track of
      the total number of cpus that need to free the corresponding
      vectors associated with the irq which has now been migrated to
      new destination. As long as this move_cleanup_count is non-zero
      (i.e., as long as we have n't freed the vector allocations on
      the old destinations) we were preventing the irq's further
      migration.
      
      This cleanup count is unnecessary and it is enough to not allow
      the irq migration till we send the cleanup vector to the
      previous irq destination, for which we already have irq_cfg's
      move_in_progress.  All we need to make sure is that we free the
      vector at the old desintation but we don't need to wait till
      that gets freed.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: default avatarGary Hade <garyhade@us.ibm.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <20091026230001.752968906@sbs-t61.sc.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      23359a88
    • Suresh Siddha's avatar
      x86, intr-remap: Avoid irq_chip mask/unmask in fixup_irqs() for intr-remapping · 84e21493
      Suresh Siddha authored
      In the presence of interrupt-remapping, irqs will be migrated in
      the process context and we don't do (and there is no need to)
      irq_chip mask/unmask while migrating the interrupt.
      
      Similarly fix the fixup_irqs() that get called during cpu
      offline and avoid calling irq_chip mask/unmask for irqs that are
      ok to be migrated in the process context.
      
      While we didn't observe any race condition with the existing
      code, this change takes complete advantage of
      interrupt-remapping in the newer generation platforms and avoids
      any potential HW lockup's (that often worry Eric :)
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: garyhade@us.ibm.com
      LKML-Reference: <20091026230001.661423939@sbs-t61.sc.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      84e21493
    • Suresh Siddha's avatar
      x86: Unify fixup_irqs() for 32-bit and 64-bit kernels · 7a7732bc
      Suresh Siddha authored
      There is no reason to have different fixup_irqs() for 32-bit and
      64-bit kernels. Unify by using the superior 64-bit version for
      both the kernels.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarGary Hade <garyhade@us.ibm.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <20091026230001.562512739@sbs-t61.sc.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7a7732bc
  4. 27 Oct, 2009 1 commit
  5. 15 Oct, 2009 1 commit
    • Cyrill Gorcunov's avatar
      x86: apic: Allow noop operations to be called almost at any time · f88f2b4f
      Cyrill Gorcunov authored
      As only apic noop is used we allow to use almost any operation
      caller wants (and which of them noop driver supports of
      course).
      
      Initially it was reported by Ingo Molnar that apic noop
      issue a warning for pkg id (which is actually false positive
      and should be eliminated).
      
      So we save checking (and warning issue) for read/write
      operations while allow any other ops to be freely used.
      
      Also:
       - fix noop_cpu_to_logical_apicid, it should be 0.
       - rename noop_default_phys_pkg_id to noop_phys_pkg_id
         (we use default_ prefix for more general routines
          in apic subsystem).
      Reported-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      LKML-Reference: <20091015150416.GC5331@lenovo>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f88f2b4f
  6. 14 Oct, 2009 7 commits
  7. 13 Oct, 2009 18 commits
  8. 12 Oct, 2009 3 commits