1. 05 3月, 2014 1 次提交
    • T
      x86: Hyperv: Cleanup the irq mess · 1aec1696
      Thomas Gleixner 提交于
      The vmbus/hyperv interrupt handling is another complete trainwreck and
      probably the worst of all currently in tree.
      
      If CONFIG_HYPERV=y then the interrupt delivery to the vmbus happens
      via the direct HYPERVISOR_CALLBACK_VECTOR. So far so good, but:
      
        The driver requests first a normal device interrupt. The only reason
        to do so is to increment the interrupt stats of that device
        interrupt. For no reason it also installs a private flow handler.
      
        We have proper accounting mechanisms for direct vectors, but of
        course it's too much effort to add that 5 lines of code.
      
        Aside of that the alloc_intr_gate() is not protected against
        reallocation which makes module reload impossible.
      
      Solution to the problem is simple to rip out the whole mess and
      implement it correctly.
      
      First of all move all that code to arch/x86/kernel/cpu/mshyperv.c and
      merily install the HYPERVISOR_CALLBACK_VECTOR with proper reallocation
      protection and use the proper direct vector accounting mechanism.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NK. Y. Srinivasan <kys@microsoft.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: linuxdrivers <devel@linuxdriverproject.org>
      Cc: x86 <x86@kernel.org>
      Link: http://lkml.kernel.org/r/20140223212739.028307673@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      1aec1696
  2. 08 2月, 2014 2 次提交
  3. 28 1月, 2014 1 次提交
  4. 19 12月, 2013 1 次提交
  5. 07 12月, 2013 1 次提交
    • L
      ACPI: Clean up inclusions of ACPI header files · 8b48463f
      Lv Zheng 提交于
      Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
      <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
      inclusions and remove some inclusions of those files that aren't
      necessary.
      
      First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
      should not be included directly from any files that are built for
      CONFIG_ACPI unset, because that generally leads to build warnings about
      undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
      <linux/acpi.h> includes those files and for CONFIG_ACPI unset it
      provides stub ACPI symbols to be used in that case.
      
      Second, there are ordering dependencies between those files that always
      have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
      prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
      latter depends on are always there.  And <acpi/acpi.h> which provides
      basic ACPICA type declarations should always be included prior to any other
      ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
      <linux/acpi.h> as appropriate.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8b48463f
  6. 20 10月, 2013 1 次提交
  7. 18 10月, 2013 1 次提交
  8. 17 10月, 2013 2 次提交
  9. 27 9月, 2013 16 次提交
  10. 26 9月, 2013 1 次提交
  11. 31 8月, 2013 1 次提交
  12. 28 8月, 2013 1 次提交
  13. 02 8月, 2013 1 次提交
  14. 27 7月, 2013 2 次提交
  15. 17 7月, 2013 3 次提交
  16. 25 6月, 2013 2 次提交
  17. 19 6月, 2013 1 次提交
  18. 04 6月, 2013 1 次提交
    • K
      Drivers: hv: vmbus: Implement multi-channel support · e68d2971
      K. Y. Srinivasan 提交于
      Starting with Win8, the host supports multiple sub-channels for a given
      device. As in the past, the initial channel offer specifies the device and
      is associated with both the type and the instance GUIDs. For performance
      critical devices, the host may support multiple sub-channels. The sub-channels
      share the same type and instance GUID as the primary channel. The number of
      sub-channels offerrred to the guest depends on the number of virtual CPUs
      assigned to the guest. The guest can request the creation of these sub-channels
      and once created and opened, the guest can distribute the traffic across all
      the channels (the primary and the sub-channels). A request sent on a sub-channel
      will have the response delivered on the same sub-channel.
      
      At channel (sub-channel) creation we bind the channel interrupt to a CPU and
      with this sub-channel support we will be able to spread the interrupt load
      of a given device across all available CPUs.
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Reviewed-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e68d2971
  19. 22 5月, 2013 1 次提交