1. 07 9月, 2019 1 次提交
  2. 03 7月, 2019 1 次提交
    • M
      clocksource/drivers: Make Hyper-V clocksource ISA agnostic · fd1fea68
      Michael Kelley 提交于
      Hyper-V clock/timer code and data structures are currently mixed
      in with other code in the ISA independent drivers/hv directory as
      well as the ISA dependent Hyper-V code under arch/x86.
      
      Consolidate this code and data structures into a Hyper-V clocksource driver
      to better follow the Linux model. In doing so, separate out the ISA
      dependent portions so the new clocksource driver works for x86 and for the
      in-process Hyper-V on ARM64 code.
      
      To start, move the existing clockevents code to create the new clocksource
      driver. Update the VMbus driver to call initialization and cleanup routines
      since the Hyper-V synthetic timers are not independently enumerated in
      ACPI.
      
      No behavior is changed and no new functionality is added.
      Suggested-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: "bp@alien8.de" <bp@alien8.de>
      Cc: "will.deacon@arm.com" <will.deacon@arm.com>
      Cc: "catalin.marinas@arm.com" <catalin.marinas@arm.com>
      Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>
      Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>
      Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
      Cc: "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>
      Cc: "olaf@aepfle.de" <olaf@aepfle.de>
      Cc: "apw@canonical.com" <apw@canonical.com>
      Cc: "jasowang@redhat.com" <jasowang@redhat.com>
      Cc: "marcelo.cerri@canonical.com" <marcelo.cerri@canonical.com>
      Cc: Sunil Muthuswamy <sunilmut@microsoft.com>
      Cc: KY Srinivasan <kys@microsoft.com>
      Cc: "sashal@kernel.org" <sashal@kernel.org>
      Cc: "vincenzo.frascino@arm.com" <vincenzo.frascino@arm.com>
      Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>
      Cc: "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>
      Cc: "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>
      Cc: "arnd@arndb.de" <arnd@arndb.de>
      Cc: "linux@armlinux.org.uk" <linux@armlinux.org.uk>
      Cc: "ralf@linux-mips.org" <ralf@linux-mips.org>
      Cc: "paul.burton@mips.com" <paul.burton@mips.com>
      Cc: "daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>
      Cc: "salyzyn@android.com" <salyzyn@android.com>
      Cc: "pcc@google.com" <pcc@google.com>
      Cc: "shuah@kernel.org" <shuah@kernel.org>
      Cc: "0x7f454c46@gmail.com" <0x7f454c46@gmail.com>
      Cc: "linux@rasmusvillemoes.dk" <linux@rasmusvillemoes.dk>
      Cc: "huw@codeweavers.com" <huw@codeweavers.com>
      Cc: "sfr@canb.auug.org.au" <sfr@canb.auug.org.au>
      Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>
      Cc: "rkrcmar@redhat.com" <rkrcmar@redhat.com>
      Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
      Link: https://lkml.kernel.org/r/1561955054-1838-2-git-send-email-mikelley@microsoft.com
      fd1fea68
  3. 05 6月, 2019 1 次提交
  4. 11 4月, 2019 1 次提交
    • K
      Drivers: hv: vmbus: Fix race condition with new ring_buffer_info mutex · 14948e39
      Kimberly Brown 提交于
      Fix a race condition that can result in a ring buffer pointer being set
      to null while a "_show" function is reading the ring buffer's data. This
      problem was discussed here: https://lkml.org/lkml/2018/10/18/779
      
      To fix the race condition, add a new mutex lock to the
      "hv_ring_buffer_info" struct. Add a new function,
      "hv_ringbuffer_pre_init()", where a channel's inbound and outbound
      ring_buffer_info mutex locks are initialized.
      
      Acquire/release the locks in the "hv_ringbuffer_cleanup()" function,
      which is where the ring buffer pointers are set to null.
      
      Acquire/release the locks in the four channel-level "_show" functions
      that access ring buffer data. Remove the "const" qualifier from the
      "vmbus_channel" parameter and the "rbi" variable of the channel-level
      "_show" functions so that the locks can be acquired/released in these
      functions.
      
      Acquire/release the locks in hv_ringbuffer_get_debuginfo(). Remove the
      "const" qualifier from the "hv_ring_buffer_info" parameter so that the
      locks can be acquired/released in this function.
      Signed-off-by: NKimberly Brown <kimbrownkd@gmail.com>
      Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      14948e39
  5. 21 3月, 2019 1 次提交
    • K
      Drivers: hv: vmbus: Expose monitor data only when monitor pages are used · 46fc1548
      Kimberly Brown 提交于
      There are two methods for signaling the host: the monitor page mechanism
      and hypercalls. The monitor page mechanism is used by performance
      critical channels (storage, networking, etc.) because it provides
      improved throughput. However, latency is increased. Monitor pages are
      allocated to these channels.
      
      Monitor pages are not allocated to channels that do not use the monitor
      page mechanism. Therefore, these channels do not have a valid monitor id
      or valid monitor page data. In these cases, some of the "_show"
      functions return incorrect data. They return an invalid monitor id and
      data that is beyond the bounds of the hv_monitor_page array fields.
      
      The "channel->offermsg.monitor_allocated" value can be used to determine
      whether monitor pages have been allocated to a channel.
      
      Add "is_visible()" callback functions for the device-level and
      channel-level attribute groups. These functions will hide the monitor
      sysfs files when the monitor mechanism is not used.
      
      Remove ".default_attributes" from "vmbus_chan_attrs" and create a
      channel-level attribute group. These changes allow the new
      "is_visible()" callback function to be applied to the channel-level
      attributes.
      
      Call "sysfs_create_group()" in "vmbus_add_channel_kobj()" to create the
      channel's sysfs files. Add a new function,
      “vmbus_remove_channel_attr_group()”, and call it in "free_channel()" to
      remove the channel's sysfs files when the channel is closed.
      Signed-off-by: NKimberly Brown <kimbrownkd@gmail.com>
      Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      46fc1548
  6. 15 2月, 2019 1 次提交
  7. 15 12月, 2018 1 次提交
  8. 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
  9. 12 11月, 2018 1 次提交
  10. 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
  11. 29 3月, 2018 1 次提交
  12. 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
  13. 04 11月, 2017 1 次提交
  14. 04 10月, 2017 1 次提交
  15. 10 8月, 2017 1 次提交
  16. 18 5月, 2017 2 次提交
  17. 17 3月, 2017 3 次提交
  18. 15 2月, 2017 5 次提交
  19. 10 2月, 2017 2 次提交
  20. 31 1月, 2017 1 次提交
  21. 20 1月, 2017 5 次提交
  22. 19 1月, 2017 3 次提交
  23. 11 1月, 2017 2 次提交
  24. 07 11月, 2016 2 次提交