1. 25 11月, 2016 1 次提交
    • S
      VSOCK: add loopback to virtio_transport · b9116823
      Stefan Hajnoczi 提交于
      The VMware VMCI transport supports loopback inside virtual machines.
      This patch implements loopback for virtio-vsock.
      
      Flow control is handled by the virtio-vsock protocol as usual.  The
      sending process stops transmitting on a connection when the peer's
      receive buffer space is exhausted.
      
      Cathy Avery <cavery@redhat.com> noticed this difference between VMCI and
      virtio-vsock when a test case using loopback failed.  Although loopback
      isn't the main point of AF_VSOCK, it is useful for testing and
      virtio-vsock must match VMCI semantics so that userspace programs run
      regardless of the underlying transport.
      
      My understanding is that loopback is not supported on the host side with
      VMCI.  Follow that by implementing it only in the guest driver, not the
      vhost host driver.
      
      Cc: Jorgen Hansen <jhansen@vmware.com>
      Reported-by: NCathy Avery <cavery@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9116823
  2. 23 11月, 2016 1 次提交
    • D
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · f9aa9dc7
      David S. Miller 提交于
      All conflicts were simple overlapping changes except perhaps
      for the Thunder driver.
      
      That driver has a change_mtu method explicitly for sending
      a message to the hardware.  If that fails it returns an
      error.
      
      Normally a driver doesn't need an ndo_change_mtu method becuase those
      are usually just range changes, which are now handled generically.
      But since this extra operation is needed in the Thunder driver, it has
      to stay.
      
      However, if the message send fails we have to restore the original
      MTU before the change because the entire call chain expects that if
      an error is thrown by ndo_change_mtu then the MTU did not change.
      Therefore code is added to nicvf_change_mtu to remember the original
      MTU, and to restore it upon nicvf_update_hw_max_frs() failue.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9aa9dc7
  3. 22 11月, 2016 38 次提交