23 Apr, 2020

1 commit

  • The fcopy and vss callback functions could be running in a tasklet
    at the same time they are called in hv_poll_channel(). Current code
    serializes the invocations of these functions, and their accesses to
    the channel ring buffer, by sending an IPI to the CPU that is allowed
    to access the ring buffer, cf. hv_poll_channel(). This IPI mechanism
    becomes infeasible if we allow changing the CPU that a channel will
    interrupt. Instead modify the callback wrappers to always execute
    the fcopy and vss callbacks in a tasklet, thus mirroring the solution
    for the kvp callback functions adopted since commit a3ade8cc474d8
    ("HV: properly delay KVP packets when negotiation is in progress").
    This will ensure that the callback function can't run on two CPUs at
    the same time.

    Suggested-by: Michael Kelley
    Signed-off-by: Andrea Parri (Microsoft)
    Link: https://lore.kernel.org/r/20200406001514.19876-6-parri.andrea@gmail.com
    Reviewed-by: Michael Kelley
    Signed-off-by: Wei Liu

    Andrea Parri (Microsoft)
     

27 Jan, 2020

1 commit

  • Add util_pre_suspend() and util_pre_resume() for some hv_utils devices
    (e.g. kvp/vss/fcopy), because they need special handling before
    util_suspend() calls vmbus_close().

    For kvp, all the possible pending work items should be cancelled.

    For vss and fcopy, some extra clean-up needs to be done, i.e. fake a
    THAW message for hv_vss_daemon and fake a CANCEL_FCOPY message for
    hv_fcopy_daemon, otherwise when the VM resums back, the daemons
    can end up in an inconsistent state (i.e. the file systems are
    frozen but will never be thawed; the file transmitted via fcopy
    may not be complete). Note: there is an extra patch for the daemons:
    "Tools: hv: Reopen the devices if read() or write() returns errors",
    because the hv_utils driver can not guarantee the whole transaction
    finishes completely once util_suspend() starts to run (at this time,
    all the userspace processes are frozen).

    util_probe() disables channel->callback_event to avoid the race with
    the channel callback.

    Signed-off-by: Dexuan Cui
    Reviewed-by: Michael Kelley
    Signed-off-by: Sasha Levin

    Dexuan Cui
     

22 Nov, 2019

1 commit

  • The recv_buffer is used to retrieve data from the VMbus ring buffer.
    VMbus ring buffers are sized based on the guest page size which
    Hyper-V assumes to be 4KB. But it may be different on some
    architectures. So use the Hyper-V page size to allocate the
    recv_buffer and set the maximum size to receive.

    Signed-off-by: Himadri Pandya
    Reviewed-by: Michael Kelley
    Signed-off-by: Sasha Levin

    Himadri Pandya
     

05 Jun, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation this program is
    distributed in the hope that it will be useful but without any
    warranty without even the implied warranty of merchantability or
    fitness for a particular purpose good title or non infringement see
    the gnu general public license for more details

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 9 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Alexios Zavras
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190529141900.459653302@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

27 Mar, 2017

1 commit


17 Mar, 2017

1 commit


16 Mar, 2017

1 commit

  • Waiting for release_event in all three drivers introduced issues on release
    as on_reset() hook is not always called. E.g. if the device was never
    opened we will never get the completion.

    Move the waiting code to hvutil_transport_destroy() and make sure it is
    only called when the device is open. hvt->lock serialization should
    guarantee the absence of races.

    Fixes: 5a66fecbf6aa ("Drivers: hv: util: kvp: Fix a rescind processing issue")
    Fixes: 20951c7535b5 ("Drivers: hv: util: Fcopy: Fix a rescind processing issue")
    Fixes: d77044d142e9 ("Drivers: hv: util: Backup: Fix a rescind processing issue")

    Reported-by: Dexuan Cui
    Tested-by: Dexuan Cui
    Signed-off-by: Vitaly Kuznetsov
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     

31 Jan, 2017

2 commits

  • Log the negotiated IC versions.

    Signed-off-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Alex Ng
     
  • Previously, we were assuming that each IC protocol version was tied to a
    specific host version. For example, some Windows 10 preview hosts only
    support v3 TimeSync even though driver assumes v4 is supported by all
    Windows 10 hosts.

    The guest will stop trying to negotiate even though older supported
    versions may still be offered by the host.

    Make IC version negotiation more robust by going through all versions
    that are supported by the guest.

    Fixes: 3da0401b4d0e ("Drivers: hv: utils: Fix the mapping between host
    version and protocol to use")

    Reported-by: Rolf Neugebauer
    Signed-off-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Alex Ng
     

11 Jan, 2017

1 commit

  • VSS may use a char device to support the communication between
    the user level daemon and the driver. When the VSS channel is rescinded
    we need to make sure that the char device is fully cleaned up before
    we can process a new VSS offer from the host. Implement this logic.

    Signed-off-by: K. Y. Srinivasan
    Cc:
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan
     

07 Nov, 2016

2 commits


02 Sep, 2016

2 commits

  • Hyper-V host will send a VSS_OP_HOT_BACKUP request to check if guest is
    ready for a live backup/snapshot. The driver should respond to the check
    only if the daemon is running and listening to requests. This allows the
    host to fallback to standard snapshots in case the VSS daemon is not
    running.

    Signed-off-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Alex Ng
     
  • Multiple VSS_OP_HOT_BACKUP requests may arrive in quick succession, even
    though the host only signals once. The driver wass handling the first
    request while ignoring the others in the ring buffer. We should poll the
    VSS channel after handling a request to continue processing other requests.

    Signed-off-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Alex Ng
     

31 Aug, 2016

1 commit

  • Background: userspace daemons registration protocol for Hyper-V utilities
    drivers has two steps:
    1) daemon writes its own version to kernel
    2) kernel reads it and replies with module version
    at this point we consider the handshake procedure being completed and we
    do hv_poll_channel() transitioning the utility device to HVUTIL_READY
    state. At this point we're ready to handle messages from kernel.

    When hvutil_transport is in HVUTIL_TRANSPORT_CHARDEV mode we have a
    single buffer for outgoing message. hvutil_transport_send() puts to this
    buffer and till the buffer is cleared with hvt_op_read() returns -EFAULT
    to all consequent calls. Hostguest protocol guarantees there is no more
    than one request at a time and we will not get new requests till we reply
    to the previous one so this single message buffer is enough.

    Now to the race. When we finish negotiation procedure and send kernel
    module version to userspace with hvutil_transport_send() it goes into the
    above mentioned buffer and if the daemon is slow enough to read it from
    there we can get a collision when a request from the host comes, we won't
    be able to put anything to the buffer so the request will be lost. To
    solve the issue we need to know when the negotiation is really done (when
    the version message is read by the daemon) and transition to HVUTIL_READY
    state after this happens. Implement a callback on read to support this.
    Old style netlink communication is not affected by the change, we don't
    really know when these messages are delivered but we don't have a single
    message buffer there.

    Reported-by: Barry Davis
    Signed-off-by: Vitaly Kuznetsov
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     

02 Mar, 2016

1 commit

  • Pass the channel information to the util drivers that need to defer
    reading the channel while they are processing a request. This would address
    the following issue reported by Vitaly:

    Commit 3cace4a61610 ("Drivers: hv: utils: run polling callback always in
    interrupt context") removed direct *_transaction.state = HVUTIL_READY
    assignments from *_handle_handshake() functions introducing the following
    race: if a userspace daemon connects before we get first non-negotiation
    request from the server hv_poll_channel() won't set transaction state to
    HVUTIL_READY as (!channel) condition will fail, we set it to non-NULL on
    the first real request from the server.

    Signed-off-by: K. Y. Srinivasan
    Reported-by: Vitaly Kuznetsov
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan
     

15 Dec, 2015

3 commits

  • When the handshake with daemon is complete, we should poll the channel since
    during the handshake, we will not be processing any messages. This is a
    potential bug if the host is waiting for a response from the guest.
    I would like to thank Dexuan for pointing this out.

    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan
     
  • The Backup integration service on WS2012 has appearently trouble to
    negotiate with a guest which does not support the provided util version.
    Currently the VSS driver supports only version 5/0. A WS2012 offers only
    version 1/x and 3/x, and vmbus_prep_negotiate_resp correctly returns an
    empty icframe_vercnt/icmsg_vercnt. But the host ignores that and
    continues to send ICMSGTYPE_NEGOTIATE messages. The result are weird
    errors during boot and general misbehaviour.

    Check the Windows version to work around the host bug, skip hv_vss_init
    on WS2012 and older.

    Signed-off-by: Olaf Hering
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Olaf Hering
     
  • All channel interrupts are bound to specific VCPUs in the guest
    at the point channel is created. While currently, we invoke the
    polling function on the correct CPU (the CPU to which the channel
    is bound to) in some cases we may run the polling function in
    a non-interrupt context. This potentially can cause an issue as the
    polling function can be interrupted by the channel callback function.
    Fix the issue by running the polling function on the appropriate CPU
    at interrupt level. Additional details of the issue being addressed by
    this patch are given below:

    Currently hv_fcopy_onchannelcallback is called from interrupts and also
    via the ->write function of hv_utils. Since the used global variables to
    maintain state are not thread safe the state can get out of sync.
    This affects the variable state as well as the channel inbound buffer.

    As suggested by KY adjust hv_poll_channel to always run the given
    callback on the cpu which the channel is bound to. This avoids the need
    for locking because all the util services are single threaded and only
    one transaction is active at any given point in time.

    Additionally, remove the context variable, they will always be the same as
    recv_channel.

    Signed-off-by: Olaf Hering
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Olaf Hering
     

25 May, 2015

6 commits

  • Unify driver registration reporting and move it to debug level as normally daemons write to syslog themselves
    and these kernel messages are useless.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • Introduce VSS_OP_REGISTER1 to support kernel replying to the negotiation
    message with its own version.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • Convert to hv_utils_transport to support both netlink and /dev/vmbus/hv_vss communication methods.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • Switch to using the hvutil_device_state state machine from using kvp_transaction.active.

    State transitions are:
    -> HVUTIL_DEVICE_INIT when driver loads or on device release
    -> HVUTIL_READY if the handshake was successful
    -> HVUTIL_HOSTMSG_RECEIVED when there is a non-negotiation message from the host
    -> HVUTIL_USERSPACE_REQ after we sent the message to the userspace daemon
    -> HVUTIL_USERSPACE_RECV after/if the userspace daemon has replied
    -> HVUTIL_READY after we respond to the host
    -> HVUTIL_DEVICE_DYING on driver unload

    In hv_vss_onchannelcallback() process ICMSGTYPE_NEGOTIATE messages even when
    the userspace daemon is disconnected, otherwise we can make the host think
    we don't support VSS and disable the service completely.

    Unfortunately there is no good way we can figure out that the userspace daemon
    has died (unless we start treating all timeouts as such), add a protection
    against processing new VSS_OP_REGISTER messages while being in the middle of a
    transaction (HVUTIL_USERSPACE_REQ or HVUTIL_USERSPACE_RECV state).

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • In theory, the host is not supposed to issue any requests before be reply to
    the previous one. In KVP we, however, support the following scenarios:
    1) A message was received before userspace daemon registered;
    2) A message was received while the previous one is still being processed.
    In VSS we support only the former. Add support for the later, use
    hv_poll_channel() to do the job.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • These declarations are internal to hv_util module and hv_fcopy_* declarations
    already reside there.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     

27 Nov, 2014

2 commits

  • If we fail to send a message to userspace daemon with cn_netlink_send()
    there is no need to wait for userspace to reply as it is not going to
    happen. This happens when kvp or vss daemon is stopped after a successful
    handshake. Report HV_E_FAIL immediately and cancel the timeout job so
    host won't receive two failures.
    Use pr_warn() for VSS and pr_debug() for KVP deliberately as VSS request
    are rare and result in a failed backup. KVP requests are much more frequent
    after a successful handshake so avoid flooding logs. It would be nice to
    have an ability to de-negotiate with the host in case userspace daemon gets
    disconnected so we won't receive new requests. But I'm not sure it is
    possible.

    Signed-off-by: Vitaly Kuznetsov
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • In contrast with KVP there is no timeout when communicating with
    userspace VSS daemon. In case it gets stuck performing freeze/thaw
    operation no message will be sent to the host so it will take very
    long (around 10 minutes) before backup fails. Introduce 10 second
    timeout using schedule_delayed_work().

    Signed-off-by: Vitaly Kuznetsov
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     

08 Feb, 2014

1 commit


27 Sep, 2013

1 commit

  • The current code does not correctly negotiate the version numbers for the util
    driver when hosted on earlier hosts. The version numbers presented by this
    driver were not compatible with the version numbers supported by Windows Server
    2008. Fix this problem.

    I would like to thank Olaf Hering (ohering@suse.com) for identifying the problem.

    Reported-by: Olaf Hering
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan
     

27 Jul, 2013

1 commit


16 Mar, 2013

1 commit

  • This driver supports host initiated backup of the guest. On Windows guests,
    the host can generate application consistent backups using the Windows VSS
    framework. On Linux, we ensure that the backup will be file system consistent.
    This driver allows the host to initiate a "Freeze" operation on all the mounted
    file systems in the guest. Once the mounted file systems in the guest are frozen,
    the host snapshots the guest's file systems. Once this is done, the guest's file
    systems are "thawed".

    This driver has a user-level component (daemon) that invokes the appropriate
    operation on all the mounted file systems in response to the requests from
    the host. The duration for which the guest is frozen is very short - a few seconds.
    During this interval, the diff disk is comitted.

    In this version of the patch I have addressed the feedback from Olaf Herring.
    Also, some of the connector related issues have been fixed.

    Signed-off-by: K. Y. Srinivasan
    Reviewed-by: Haiyang Zhang
    Cc: Evgeniy Polyakov
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan