1. 26 9月, 2017 6 次提交
    • T
      x86/io_apic: Reevaluate vector configuration on activate() · 90ad9e2d
      Thomas Gleixner 提交于
      With the upcoming reservation/management scheme, early activation will
      assign a special vector. The final activation at request_irq() assigns a
      real vector, which needs to be updated in the ioapic.
      
      Split out the reconfiguration code in set_affinity and use it for
      reactivation.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJuergen Gross <jgross@suse.com>
      Tested-by: NYu Chen <yu.c.chen@intel.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Rui Zhang <rui.zhang@intel.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Link: https://lkml.kernel.org/r/20170913213156.025232175@linutronix.de
      90ad9e2d
    • T
      x86/ioapic: Mark legacy vectors at reallocation time · 3534be05
      Thomas Gleixner 提交于
      When the legacy PIC vectors are taken over by the IO APIC the current
      vector assignement code is tricked to reuse the vector by allocating the
      apic data in the early boot process. This can be avoided by marking the
      allocation as legacy PIC take over. Preparatory patch for further cleanups.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJuergen Gross <jgross@suse.com>
      Tested-by: NYu Chen <yu.c.chen@intel.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Rui Zhang <rui.zhang@intel.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Link: https://lkml.kernel.org/r/20170913213154.700501979@linutronix.de
      3534be05
    • T
      x86/ioapic: Remove obsolete post hotplug update · ef9e56d8
      Thomas Gleixner 提交于
      With single CPU affinities the post SMP boot vector update is pointless as
      it will just leave the affinities on the same vectors and the same CPUs.
      
      Remove it.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJuergen Gross <jgross@suse.com>
      Tested-by: NYu Chen <yu.c.chen@intel.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Rui Zhang <rui.zhang@intel.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Link: https://lkml.kernel.org/r/20170913213154.308697243@linutronix.de
      ef9e56d8
    • T
      x86/apic: Get rid of apic->target_cpus · c1d1ee9a
      Thomas Gleixner 提交于
      The target_cpus() callback of the apic struct is not really useful. Some
      APICs return cpu_online_mask and others cpus_all_mask. The latter is bogus
      as it does not take holes in the cpus_possible_mask into account.
      
      Replace it with cpus_online_mask which makes the most sense and remove the
      callback.
      
      The usage sites will be removed in a later step anyway, so get rid of it
      now to have incremental changes.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJuergen Gross <jgross@suse.com>
      Tested-by: NYu Chen <yu.c.chen@intel.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Rui Zhang <rui.zhang@intel.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Link: https://lkml.kernel.org/r/20170913213154.070850916@linutronix.de
      c1d1ee9a
    • T
      genirq/irqdomain: Propagate early activation · 42e1cc2d
      Thomas Gleixner 提交于
      Propagate the early activation mode to the irqdomain activate()
      callbacks. This is required for the upcoming reservation, late vector
      assignment scheme, so that the early activation call can act accordingly.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJuergen Gross <jgross@suse.com>
      Tested-by: NYu Chen <yu.c.chen@intel.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Rui Zhang <rui.zhang@intel.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Link: https://lkml.kernel.org/r/20170913213153.028353660@linutronix.de
      42e1cc2d
    • T
      genirq/irqdomain: Update irq_domain_ops.activate() signature · 72491643
      Thomas Gleixner 提交于
      The irq_domain_ops.activate() callback has no return value and no way to
      tell the function that the activation is early.
      
      The upcoming changes to support a reservation scheme which allows to assign
      interrupt vectors on x86 only when the interrupt is actually requested
      requires:
      
        - A return value, so activation can fail at request_irq() time
        
        - Information that the activate invocation is early, i.e. before
          request_irq().
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJuergen Gross <jgross@suse.com>
      Tested-by: NYu Chen <yu.c.chen@intel.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Rui Zhang <rui.zhang@intel.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Link: https://lkml.kernel.org/r/20170913213152.848490816@linutronix.de
      72491643
  2. 25 9月, 2017 1 次提交
    • D
      x86/ioapic: Refactor the delay logic in timer_irq_works() · ca7c6076
      Dou Liyang 提交于
      timer_irq_works() is used to detects the timer IRQs. It calls mdelay(10) to
      delay ten ticks and check whether the timer IRQ work or not.
      
      mdelay() depends on the loops_per_jiffy which is set up in
      calibrate_delay(), but the delay calibration depends on a working timer
      interrupt, which causes a chicken and egg problem.
      
      The correct solution is to set up the interrupt mode and making sure that
      the timer interrupt is delivered correctly before invoking calibrate_delay().
      That means that mdelay() cannot be used in timer_irq_works(). 
      
      Provide helper functions to make a rough delay estimate which is good enough
      to prove that the timer interrupt is working. Either use TSC or a simple
      delay loop and assume that 4GHz is the maximum CPU frequency to base the
      delay calculation on.
      Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: yinghai@kernel.org
      Cc: bhe@redhat.com
      Link: https://lkml.kernel.org/r/1505293975-26005-9-git-send-email-douly.fnst@cn.fujitsu.com
      ca7c6076
  3. 23 8月, 2017 1 次提交
  4. 20 7月, 2017 1 次提交
  5. 23 6月, 2017 1 次提交
  6. 26 5月, 2017 1 次提交
  7. 09 2月, 2017 1 次提交
    • L
      Revert "x86/ioapic: Restore IO-APIC irq_chip retrigger callback" · d966564f
      Linus Torvalds 提交于
      This reverts commit 020eb3da.
      
      Gabriel C reports that it causes his machine to not boot, and we haven't
      tracked down the reason for it yet.  Since the bug it fixes has been
      around for a longish time, we're better off reverting the fix for now.
      
      Gabriel says:
       "It hangs early and freezes with a lot RCU warnings.
      
        I bisected it down to :
      
        > Ruslan Ruslichenko (1):
        >       x86/ioapic: Restore IO-APIC irq_chip retrigger callback
      
        Reverting this one fixes the problem for me..
      
        The box is a PRIMERGY TX200 S5 , 2 socket , 2 x E5520 CPU(s) installed"
      
      and Ruslan and Thomas are currently stumped.
      Reported-and-bisected-by: NGabriel C <nix.or.die@gmail.com>
      Cc: Ruslan Ruslichenko <rruslich@cisco.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@kernel.org   # for the backport of the original commit
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d966564f
  8. 01 2月, 2017 1 次提交
  9. 20 1月, 2017 1 次提交
  10. 18 1月, 2017 2 次提交
  11. 10 12月, 2016 1 次提交
  12. 20 9月, 2016 1 次提交
  13. 14 7月, 2016 1 次提交
    • P
      x86/kernel: Audit and remove any unnecessary uses of module.h · 186f4360
      Paul Gortmaker 提交于
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.  The advantage
      in doing so is that module.h itself sources about 15 other headers;
      adding significantly to what we feed cpp, and it can obscure what
      headers we are effectively using.
      
      Since module.h was the source for init.h (for __init) and for
      export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance
      for the presence of either and replace as needed.  Build testing
      revealed some implicit header usage that was fixed up accordingly.
      
      Note that some bool/obj-y instances remain since module.h is
      the header for some exception table entry stuff, and for things
      like __init_or_module (code that is tossed when MODULES=n).
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160714001901.31603-4-paul.gortmaker@windriver.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      186f4360
  14. 04 7月, 2016 1 次提交
  15. 10 6月, 2016 2 次提交
  16. 13 4月, 2016 1 次提交
  17. 15 1月, 2016 1 次提交
  18. 27 10月, 2015 1 次提交
    • W
      x86/ioapic: Prevent NULL pointer dereference in setup_ioapic_dest() · ababae44
      Werner Pawlitschko 提交于
      Commit 4857c91f changed the way how irq affinity is setup in
      setup_ioapic_dest() from using the core helper function to
      unconditionally calling the irq_set_affinity() callback of the
      underlying irq chip.
      
      That results in a NULL pointer dereference for the rare case where the
      underlying irq chip is lapic_chip which has no irq_set_affinity()
      callback. lapic_chip is occasionally used for the timer interrupt (irq
      0).
      
      The fix is simple: Check the availability of the callback instead of
      calling it unconditionally.
      
      Fixes: 4857c91f "x86/ioapic: Force affinity setting in setup_ioapic_dest()"
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      ababae44
  19. 16 10月, 2015 1 次提交
    • V
      x86/ioapic: Disable interrupts when re-routing legacy IRQs · c0ff971e
      Vitaly Kuznetsov 提交于
      A sporadic hang with consequent crash is observed when booting Hyper-V Gen1
      guests:
      
       Call Trace:
        <IRQ>
        [<ffffffff810ab68d>] ? trace_hardirqs_off+0xd/0x10
        [<ffffffff8107b616>] queue_work_on+0x46/0x90
        [<ffffffff81365696>] ? add_interrupt_randomness+0x176/0x1d0
        ...
        <EOI>
        [<ffffffff81471ddb>] ? _raw_spin_unlock_irqrestore+0x3b/0x60
        [<ffffffff810c295e>] __irq_put_desc_unlock+0x1e/0x40
        [<ffffffff810c5c35>] irq_modify_status+0xb5/0xd0
        [<ffffffff8104adbb>] mp_register_handler+0x4b/0x70
        [<ffffffff8104c55a>] mp_irqdomain_alloc+0x1ea/0x2a0
        [<ffffffff810c7f10>] irq_domain_alloc_irqs_recursive+0x40/0xa0
        [<ffffffff810c860c>] __irq_domain_alloc_irqs+0x13c/0x2b0
        [<ffffffff8104b070>] alloc_isa_irq_from_domain.isra.1+0xc0/0xe0
        [<ffffffff8104bfa5>] mp_map_pin_to_irq+0x165/0x2d0
        [<ffffffff8104c157>] pin_2_irq+0x47/0x80
        [<ffffffff81744253>] setup_IO_APIC+0xfe/0x802
        ...
        [<ffffffff814631c0>] ? rest_init+0x140/0x140
      
      The issue is easily reproducible with a simple instrumentation: if
      mdelay(10) is put between mp_setup_entry() and mp_register_handler() calls
      in mp_irqdomain_alloc() Hyper-V guest always fails to boot when re-routing
      IRQ0. The issue seems to be caused by the fact that we don't disable
      interrupts while doing IOPIC programming for legacy IRQs and IRQ0 actually
      happens. 
      
      Protect the setup sequence against concurrent interrupts.
      
      [ tglx: Make the protection unconditional and not only for legacy
        	interrupts ]
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Link: http://lkml.kernel.org/r/1444930943-19336-1-git-send-email-vkuznets@redhat.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      c0ff971e
  20. 12 10月, 2015 1 次提交
  21. 15 9月, 2015 1 次提交
    • T
      x86/ioapic: Force affinity setting in setup_ioapic_dest() · 4857c91f
      Thomas Gleixner 提交于
      The recent ioapic cleanups changed the affinity setting in
      setup_ioapic_dest() from a direct write to the hardware to the delayed
      affinity setup via irq_set_affinity().
      
      That results in a warning from chained_irq_exit():
      WARNING: CPU: 0 PID: 5 at kernel/irq/migration.c:32 irq_move_masked_irq
      [<ffffffff810a0a88>] irq_move_masked_irq+0xb8/0xc0
      [<ffffffff8103c161>] ioapic_ack_level+0x111/0x130
      [<ffffffff812bbfe8>] intel_gpio_irq_handler+0x148/0x1c0
      
      The reason is that irq_set_affinity() does not write directly to the
      hardware. It marks the affinity setting as pending and executes it
      from the next interrupt. The chained handler infrastructure does not
      take the irq descriptor lock for performance reasons because such a
      chained interrupt is not visible to any interfaces. So the delayed
      affinity setting triggers the warning in irq_move_masked_irq().
      
      Restore the old behaviour by calling the set_affinity function of the
      ioapic chip in setup_ioapic_dest(). This is safe as none of the
      interrupts can be on the fly at this point.
      
      Fixes: aa5cb97f 'x86/irq: Remove x86_io_apic_ops.set_affinity and related interfaces'
      Reported-and-tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: jarkko.nikula@linux.intel.com
      4857c91f
  22. 31 7月, 2015 1 次提交
  23. 14 7月, 2015 1 次提交
  24. 10 5月, 2015 1 次提交
  25. 24 4月, 2015 9 次提交