1. 15 12月, 2018 1 次提交
  2. 03 12月, 2018 1 次提交
    • D
      Drivers: hv: vmbus: Offload the handling of channels to two workqueues · 37c2578c
      Dexuan Cui 提交于
      vmbus_process_offer() mustn't call channel->sc_creation_callback()
      directly for sub-channels, because sc_creation_callback() ->
      vmbus_open() may never get the host's response to the
      OPEN_CHANNEL message (the host may rescind a channel at any time,
      e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
      may not wake up the vmbus_open() as it's blocked due to a non-zero
      vmbus_connection.offer_in_progress, and finally we have a deadlock.
      
      The above is also true for primary channels, if the related device
      drivers use sync probing mode by default.
      
      And, usually the handling of primary channels and sub-channels can
      depend on each other, so we should offload them to different
      workqueues to avoid possible deadlock, e.g. in sync-probing mode,
      NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
      rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
      and waits for all the sub-channels to appear, but the latter
      can't get the rtnl_lock and this blocks the handling of sub-channels.
      
      The patch can fix the multiple-NIC deadlock described above for
      v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
      of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
      but don't enable async-probing for Hyper-V drivers (yet).
      
      The patch can also fix the hang issue in sub-channel's handling described
      above for all versions of kernels, including v4.19 and v4.20-rc4.
      
      So actually the patch should be applied to all the existing kernels,
      not only the kernels that have 8195b139.
      
      Fixes: 8195b139 ("hv_netvsc: fix deadlock on hotplug")
      Cc: stable@vger.kernel.org
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37c2578c
  3. 12 11月, 2018 1 次提交
  4. 14 5月, 2018 1 次提交
    • D
      Drivers: hv: vmbus: enable VMBus protocol version 5.0 · ae20b254
      Dexuan Cui 提交于
      With VMBus protocol 5.0, we're able to better support new features, e.g.
      running two or more VMBus drivers simultaneously in a single VM -- note:
      we can't simply load the current VMBus driver twice, instead, a secondary
      VMBus driver must be implemented.
      
      This patch adds the support for the new VMBus protocol, which is available
      on new Windows hosts, by:
      
      1) We still use SINT2 for compatibility;
      2) We must use Connection ID 4 for the Initiate Contact Message, and for
      subsequent messages, we must use the Message Connection ID field in
      the host-returned VersionResponse Message.
      
      Notes for developers of the secondary VMBus driver:
      1) Must use VMBus protocol 5.0 as well;
      2) Must use a different SINT number that is not in use.
      3) Must use Connection ID 4 for the Initiate Contact Message, and for
      subsequent messages, must use the Message Connection ID field in
      the host-returned VersionResponse Message.
      4) It's possible that the primary VMBus driver using protocol version 4.0
      can work with a secondary VMBus driver using protocol version 5.0, but it's
      recommended that both should use 5.0 for new Hyper-V features in the future.
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Michael Kelley <mikelley@microsoft.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ae20b254
  5. 29 3月, 2018 1 次提交
  6. 07 3月, 2018 1 次提交
    • M
      Drivers: hv: vmbus: Implement Direct Mode for stimer0 · 248e742a
      Michael Kelley 提交于
      The 2016 version of Hyper-V offers the option to operate the guest VM
      per-vcpu stimer's in Direct Mode, which means the timer interupts on its
      own vector rather than queueing a VMbus message. Direct Mode reduces
      timer processing overhead in both the hypervisor and the guest, and
      avoids having timer interrupts pollute the VMbus interrupt stream for
      the synthetic NIC and storage.  This patch enables Direct Mode by
      default on stimer0 when running on a version of Hyper-V that supports
      it.
      
      In prep for coming support of Hyper-V on ARM64, the arch independent
      portion of the code contains calls to routines that will be populated
      on ARM64 but are not needed and do nothing on x86.
      Signed-off-by: NMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      248e742a
  7. 04 11月, 2017 1 次提交
  8. 04 10月, 2017 1 次提交
  9. 10 8月, 2017 1 次提交
  10. 18 5月, 2017 2 次提交
  11. 17 3月, 2017 3 次提交
  12. 15 2月, 2017 5 次提交
  13. 10 2月, 2017 2 次提交
  14. 31 1月, 2017 1 次提交
  15. 20 1月, 2017 5 次提交
  16. 19 1月, 2017 3 次提交
  17. 11 1月, 2017 2 次提交
  18. 07 11月, 2016 3 次提交
  19. 02 9月, 2016 1 次提交
  20. 31 8月, 2016 2 次提交
  21. 02 5月, 2016 2 次提交
    • V
      Drivers: hv: vmbus: handle various crash scenarios · cd95aad5
      Vitaly Kuznetsov 提交于
      Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
      delivered to the CPU which was used for initial contact or to CPU0
      depending on host version. vmbus_wait_for_unload() doesn't account for
      the fact that in case we're crashing on some other CPU we won't get the
      CHANNELMSG_UNLOAD_RESPONSE message and our wait on the current CPU will
      never end.
      
      Do the following:
      1) Check for completion_done() in the loop. In case interrupt handler is
         still alive we'll get the confirmation we need.
      
      2) Read message pages for all CPUs message page as we're unsure where
         CHANNELMSG_UNLOAD_RESPONSE is going to be delivered to. We can race with
         still-alive interrupt handler doing the same, add cmpxchg() to
         vmbus_signal_eom() to not lose CHANNELMSG_UNLOAD_RESPONSE message.
      
      3) Cleanup message pages on all CPUs. This is required (at least for the
         current CPU as we're clearing CPU0 messages now but we may want to bring
         up additional CPUs on crash) as new messages won't be delivered till we
         consume what's pending. On boot we'll place message pages somewhere else
         and we won't be able to read stale messages.
      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>
      cd95aad5
    • V
      Drivers: hv: kvp: fix IP Failover · 4dbfc2e6
      Vitaly Kuznetsov 提交于
      Hyper-V VMs can be replicated to another hosts and there is a feature to
      set different IP for replicas, it is called 'Failover TCP/IP'. When
      such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon
      as we finish negotiation procedure. The problem is that it can happen (and
      it actually happens) before userspace daemon connects and we reply with
      HV_E_FAIL to the message. As there are no repetitions we fail to set the
      requested IP.
      
      Solve the issue by postponing our reply to the negotiation message till
      userspace daemon is connected. We can't wait too long as there is a
      host-side timeout (cca. 75 seconds) and if we fail to reply in this time
      frame the whole KVP service will become inactive. The solution is not
      ideal - if it takes userspace daemon more than 60 seconds to connect
      IP Failover will still fail but I don't see a solution with our current
      separation between kernel and userspace parts.
      
      Other two modules (VSS and FCOPY) don't require such delay, leave them
      untouched.
      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>
      4dbfc2e6