1. 25 5月, 2015 2 次提交
    • V
      Drivers: hv: vmbus: unregister panic notifier on module unload · 096c605f
      Vitaly Kuznetsov 提交于
      Commit 96c1d058 ("Drivers: hv: vmbus: Add
      support for VMBus panic notifier handler") introduced
      atomic_notifier_chain_register() call on module load. We also need to call
      atomic_notifier_chain_unregister() on module unload as otherwise the following
      crash is observed when we bring hv_vmbus back:
      
      [   39.788877] BUG: unable to handle kernel paging request at ffffffffa00078a8
      [   39.788877] IP: [<ffffffff8109d63f>] notifier_call_chain+0x3f/0x80
      ...
      [   39.788877] Call Trace:
      [   39.788877]  [<ffffffff8109de7d>] __atomic_notifier_call_chain+0x5d/0x90
      ...
      [   39.788877]  [<ffffffff8109d788>] ? atomic_notifier_chain_register+0x38/0x70
      [   39.788877]  [<ffffffff8109d767>] ? atomic_notifier_chain_register+0x17/0x70
      [   39.788877]  [<ffffffffa002814f>] hv_acpi_init+0x14f/0x1000 [hv_vmbus]
      [   39.788877]  [<ffffffff81002144>] do_one_initcall+0xd4/0x210
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      096c605f
    • V
      Drivers: hv: vmbus: introduce vmbus_acpi_remove · e4ecb41c
      Vitaly Kuznetsov 提交于
      In case we do request_resource() in vmbus_acpi_add() we need to tear it down
      to be able to load the driver again. Otherwise the following crash in observed
      when hv_vmbus unload/load sequence is performed on a Generation2 instance:
      
      [   38.165701] BUG: unable to handle kernel paging request at ffffffffa00075a0
      [   38.166315] IP: [<ffffffff8107dc5f>] __request_resource+0x2f/0x50
      [   38.166315] PGD 1f34067 PUD 1f35063 PMD 3f723067 PTE 0
      [   38.166315] Oops: 0000 [#1] SMP
      [   38.166315] Modules linked in: hv_vmbus(+) [last unloaded: hv_vmbus]
      [   38.166315] CPU: 0 PID: 267 Comm: modprobe Not tainted 3.19.0-rc5_bug923184+ #486
      [   38.166315] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
      [   38.166315] task: ffff88003f401cb0 ti: ffff88003f60c000 task.ti: ffff88003f60c000
      [   38.166315] RIP: 0010:[<ffffffff8107dc5f>]  [<ffffffff8107dc5f>] __request_resource+0x2f/0x50
      [   38.166315] RSP: 0018:ffff88003f60fb58  EFLAGS: 00010286
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4ecb41c
  2. 03 4月, 2015 1 次提交
    • D
      hv: run non-blocking message handlers in the dispatch tasklet · 652594c7
      Dexuan Cui 提交于
      A work item in vmbus_connection.work_queue can sleep, waiting for a new
      host message (usually it is some kind of "completion" message). Currently
      the new message will be handled in the same workqueue, but since work items
      in the workqueue is serialized, we actually have no chance to handle
      the new message if the current work item is sleeping -- as as result, the
      current work item will hang forever.
      
      K. Y. has posted the below fix to resolve the issue:
      Drivers: hv: vmbus: Perform device register in the per-channel work element
      
      Actually we can simplify the fix by directly running non-blocking message
      handlers in the dispatch tasklet (inspired by K. Y.).
      
      This patch is the fundamental change. The following 2 patches will simplify
      the message offering and rescind-offering handling a lot.
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      652594c7
  3. 02 3月, 2015 9 次提交
    • K
      mei: bus: () can be static · ed99d846
      kbuild test robot 提交于
      drivers/hv/vmbus_drv.c:51:5: sparse: symbol 'hyperv_panic_event' was not declared. Should it be static?
      drivers/hv/vmbus_drv.c:51:5: sparse: symbol 'hyperv_panic_event' was not declared. Should it be static?
      drivers/hv/vmbus_drv.c:51:5: sparse: symbol 'hyperv_panic_event' was not declared. Should it be static?
      drivers/hv/vmbus_drv.c:51:5: sparse: symbol 'hyperv_panic_event' was not declared. Should it be static?
      Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed99d846
    • N
      Drivers: hv: vmbus: Add support for VMBus panic notifier handler · 96c1d058
      Nick Meier 提交于
      Hyper-V allows a guest to notify the Hyper-V host that a panic
      condition occured.  This notification can include up to five 64
      bit values.  These 64 bit values are written into crash MSRs.
      Once the data has been written into the crash MSRs, the host is
      then notified by writing into a Crash Control MSR.  On the Hyper-V
      host, the panic notification data is captured in the Windows Event
      log as a 18590 event.
      
      Crash MSRs are defined in appendix H of the Hypervisor Top Level
      Functional Specification.  At the time of this patch, v4.0 is the
      current functional spec.  The URL for the v4.0 document is:
      
      http://download.microsoft.com/download/A/B/4/AB43A34E-BDD0-4FA6-BDEF-79EEF16E880B/Hypervisor Top Level Functional Specification v4.0.docx
      Signed-off-by: NNick Meier <nmeier@microsoft.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96c1d058
    • K
      Drivers: hv: vmbus: Introduce a function to remove a rescinded offer · ed6cfcc5
      K. Y. Srinivasan 提交于
      In response to a rescind message, we need to remove the channel and the
      corresponding device. Cleanup this code path by factoring out the code
      to remove a channel.
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed6cfcc5
    • K
      Drivers: hv: vmbus: Properly handle child device remove · d15a0301
      K. Y. Srinivasan 提交于
      Handle the case when the device may be removed when the device has no driver
      attached to it.
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d15a0301
    • V
      Drivers: hv: vmbus: Teardown clockevent devices on module unload · e086748c
      Vitaly Kuznetsov 提交于
      Newly introduced clockevent devices made it impossible to unload hv_vmbus
      module as clockevents_config_and_register() takes additional reverence to
      the module. To make it possible again we do the following:
      - avoid setting dev->owner for clockevent devices;
      - implement hv_synic_clockevents_cleanup() doing clockevents_unbind_device();
      - call it from vmbus_exit().
      
      In theory hv_synic_clockevents_cleanup() can be merged with hv_synic_cleanup(),
      however, we call hv_synic_cleanup() from smp_call_function_single() and this
      doesn't work for clockevents_unbind_device() as it does such call on its own. I
      opted for a separate function.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e086748c
    • V
      drivers: hv: vmbus: Teardown synthetic interrupt controllers on module unload · e72e7ac5
      Vitaly Kuznetsov 提交于
      SynIC has to be switched off when we unload the module, otherwise registered
      memory pages can get corrupted after (as Hyper-V host still writes there) and
      we see the following crashes for random processes:
      
      [   89.116774] BUG: Bad page map in process sh  pte:4989c716 pmd:36f81067
      [   89.159454] addr:0000000000437000 vm_flags:00000875 anon_vma:          (null) mapping:ffff88007bba55a0 index:37
      [   89.226146] vma->vm_ops->fault: filemap_fault+0x0/0x410
      [   89.257776] vma->vm_file->f_op->mmap: generic_file_mmap+0x0/0x60
      [   89.297570] CPU: 0 PID: 215 Comm: sh Tainted: G    B          3.19.0-rc5_bug923184+ #488
      [   89.353738] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006  05/23/2012
      [   89.409138]  0000000000000000 000000004e083d7b ffff880036e9fa18 ffffffff81a68d31
      [   89.468724]  0000000000000000 0000000000437000 ffff880036e9fa68 ffffffff811a1e3a
      [   89.519233]  000000004989c716 0000000000000037 ffffea0001edc340 0000000000437000
      [   89.575751] Call Trace:
      [   89.591060]  [<ffffffff81a68d31>] dump_stack+0x45/0x57
      [   89.625164]  [<ffffffff811a1e3a>] print_bad_pte+0x1aa/0x250
      [   89.667234]  [<ffffffff811a2c95>] vm_normal_page+0x55/0xa0
      [   89.703818]  [<ffffffff811a3105>] unmap_page_range+0x425/0x8a0
      [   89.737982]  [<ffffffff811a3601>] unmap_single_vma+0x81/0xf0
      [   89.780385]  [<ffffffff81184320>] ? lru_deactivate_fn+0x190/0x190
      [   89.820130]  [<ffffffff811a4131>] unmap_vmas+0x51/0xa0
      [   89.860168]  [<ffffffff811ad12c>] exit_mmap+0xac/0x1a0
      [   89.890588]  [<ffffffff810763c3>] mmput+0x63/0x100
      [   89.919205]  [<ffffffff811eba48>] flush_old_exec+0x3f8/0x8b0
      [   89.962135]  [<ffffffff8123b5bb>] load_elf_binary+0x32b/0x1260
      [   89.998581]  [<ffffffff811a14f2>] ? get_user_pages+0x52/0x60
      
      hv_synic_cleanup() function exists but noone calls it now. Do the following:
      - call hv_synic_cleanup() on each cpu from vmbus_exit();
      - write global disable bit through MSR;
      - use hv_synic_free_cpu() to avoid memory leask and code duplication.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e72e7ac5
    • V
      Drivers: hv: vmbus: teardown hv_vmbus_con workqueue and vmbus_connection pages on shutdown · 09a19628
      Vitaly Kuznetsov 提交于
      We need to destroy hv_vmbus_con on module shutdown, otherwise the following
      crash is sometimes observed:
      
      [   76.569845] hv_vmbus: Hyper-V Host Build:9600-6.3-17-0.17039; Vmbus version:3.0
      [   82.598859] BUG: unable to handle kernel paging request at ffffffffa0003480
      [   82.599287] IP: [<ffffffffa0003480>] 0xffffffffa0003480
      [   82.599287] PGD 1f34067 PUD 1f35063 PMD 3f72d067 PTE 0
      [   82.599287] Oops: 0010 [#1] SMP
      [   82.599287] Modules linked in: [last unloaded: hv_vmbus]
      [   82.599287] CPU: 0 PID: 26 Comm: kworker/0:1 Not tainted 3.19.0-rc5_bug923184+ #488
      [   82.599287] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
      [   82.599287] Workqueue: hv_vmbus_con 0xffffffffa0003480
      [   82.599287] task: ffff88007b6ddfa0 ti: ffff88007f8f8000 task.ti: ffff88007f8f8000
      [   82.599287] RIP: 0010:[<ffffffffa0003480>]  [<ffffffffa0003480>] 0xffffffffa0003480
      [   82.599287] RSP: 0018:ffff88007f8fbe00  EFLAGS: 00010202
      ...
      
      To avoid memory leaks we need to free monitor_pages and int_page for
      vmbus_connection. Implement vmbus_disconnect() function by separating cleanup
      path from vmbus_connect().
      
      As we use hv_vmbus_con to release channels (see free_channel() in channel_mgmt.c)
      we need to make sure the work was done before we remove the queue, do that with
      drain_workqueue(). We also need to avoid handling messages  which can (potentially)
      create new channels, so set vmbus_connection.conn_state = DISCONNECTED at the very
      beginning of vmbus_exit() and check for that in vmbus_onmessage_work().
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09a19628
    • V
      Drivers: hv: vmbus: rename channel work queues · bc63b6f6
      Vitaly Kuznetsov 提交于
      All channel work queues are named 'hv_vmbus_ctl', this makes them
      indistinguishable in ps output and makes it hard to link to the corresponding
      vmbus device. Rename them to hv_vmbus_ctl/N and make vmbus device names match,
      e.g. now vmbus_1 device is served by hv_vmbus_ctl/1 work queue.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc63b6f6
    • V
      Drivers: hv: vmbus: prevent cpu offlining on newer hypervisors · e513229b
      Vitaly Kuznetsov 提交于
      When an SMP Hyper-V guest is running on top of 2012R2 Server and secondary
      cpus are sent offline (with echo 0 > /sys/devices/system/cpu/cpu$cpu/online)
      the system freeze is observed. This happens due to the fact that on newer
      hypervisors (Win8, WS2012R2, ...) vmbus channel handlers are distributed
      across all cpus (see init_vp_index() function in drivers/hv/channel_mgmt.c)
      and on cpu offlining nobody reassigns them to CPU0. Prevent cpu offlining
      when vmbus is loaded until the issue is fixed host-side.
      
      This patch also disables hibernation but it is OK as it is also broken (MCE
      error is hit on resume). Suspend still works.
      
      Tested with WS2008R2 and WS2012R2.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e513229b
  4. 26 1月, 2015 3 次提交
  5. 04 6月, 2014 1 次提交
  6. 05 3月, 2014 2 次提交
  7. 25 2月, 2014 2 次提交
  8. 08 2月, 2014 1 次提交
  9. 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
  10. 27 9月, 2013 12 次提交
  11. 02 8月, 2013 1 次提交
  12. 17 7月, 2013 1 次提交
  13. 25 6月, 2013 1 次提交
  14. 19 6月, 2013 1 次提交
  15. 28 2月, 2013 1 次提交
  16. 19 1月, 2013 1 次提交