1. 07 11月, 2016 1 次提交
  2. 13 10月, 2016 1 次提交
  3. 07 10月, 2016 1 次提交
  4. 23 9月, 2016 1 次提交
  5. 17 9月, 2016 1 次提交
    • F
      xen-netback: fix error handling on netback_probe() · cce94483
      Filipe Manco 提交于
      In case of error during netback_probe() (e.g. an entry missing on the
      xenstore) netback_remove() is called on the new device, which will set
      the device backend state to XenbusStateClosed by calling
      set_backend_state(). However, the backend state wasn't initialized by
      netback_probe() at this point, which will cause and invalid transaction
      and set_backend_state() to BUG().
      
      Initialize the backend state at the beginning of netback_probe() to
      XenbusStateInitialising, and create two new valid state transitions on
      set_backend_state(), from XenbusStateInitialising to XenbusStateClosed,
      and from XenbusStateInitialising to XenbusStateInitWait.
      Signed-off-by: NFilipe Manco <filipe.manco@neclab.eu>
      Acked-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cce94483
  6. 19 8月, 2016 1 次提交
  7. 17 5月, 2016 1 次提交
  8. 14 3月, 2016 1 次提交
  9. 08 2月, 2016 1 次提交
  10. 19 10月, 2015 1 次提交
  11. 03 9月, 2015 1 次提交
    • P
      xen-netback: add support for multicast control · 210c34dc
      Paul Durrant 提交于
      Xen's PV network protocol includes messages to add/remove ethernet
      multicast addresses to/from a filter list in the backend. This allows
      the frontend to request the backend only forward multicast packets
      which are of interest thus preventing unnecessary noise on the shared
      ring.
      
      The canonical netif header in git://xenbits.xen.org/xen.git specifies
      the message format (two more XEN_NETIF_EXTRA_TYPEs) so the minimal
      necessary changes have been pulled into include/xen/interface/io/netif.h.
      
      To prevent the frontend from extending the multicast filter list
      arbitrarily a limit (XEN_NETBK_MCAST_MAX) has been set to 64 entries.
      This limit is not specified by the protocol and so may change in future.
      If the limit is reached then the next XEN_NETIF_EXTRA_TYPE_MCAST_ADD
      sent by the frontend will be failed with NETIF_RSP_ERROR.
      Signed-off-by: NPaul Durrant <paul.durrant@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Acked-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      210c34dc
  12. 23 6月, 2015 1 次提交
    • P
      xen-netback: fix a BUG() during initialization · 12b322ac
      Palik, Imre 提交于
      Commit edafc132 ("xen-netback: making the bandwidth limiter runtime settable")
      introduced the capability to change the bandwidth rate limit at runtime.
      But it also introduced a possible crashing bug.
      
      If netback receives two XenbusStateConnected without getting the
      hotplug-status watch firing in between, then it will try to register the
      watches for the rate limiter again.  But this triggers a BUG() in the watch
      registration code.
      
      The fix modifies connect() to remove the possibly existing packet-rate
      watches before trying to install those watches.  This behaviour is in line
      with how connect() deals with the hotplug-status watch.
      Signed-off-by: NImre Palik <imrep@amazon.de>
      Cc: Matt Wilson <msw@amazon.com>
      Acked-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12b322ac
  13. 02 6月, 2015 1 次提交
    • I
      xen: netback: read hotplug script once at start of day. · 31a41898
      Ian Campbell 提交于
      When we come to tear things down in netback_remove() and generate the
      uevent it is possible that the xenstore directory has already been
      removed (details below).
      
      In such cases netback_uevent() won't be able to read the hotplug
      script and will write a xenstore error node.
      
      A recent change to the hypervisor exposed this race such that we now
      sometimes lose it (where apparently we didn't ever before).
      
      Instead read the hotplug script configuration during setup and use it
      for the lifetime of the backend device.
      
      The apparently more obvious fix of moving the transition to
      state=Closed in netback_remove() to after the uevent does not work
      because it is possible that we are already in state=Closed (in
      reaction to the guest having disconnected as it shutdown). Being
      already in Closed means the toolstack is at liberty to start tearing
      down the xenstore directories. In principal it might be possible to
      arrange to unregister the device sooner (e.g on transition to Closing)
      such that xenstore would still be there but this state machine is
      fragile and prone to anger...
      
      A modern Xen system only relies on the hotplug uevent for driver
      domains, when the backend is in the same domain as the toolstack it
      will run the necessary setup/teardown directly in the correct sequence
      wrt xenstore changes.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Acked-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31a41898
  14. 28 5月, 2015 1 次提交
  15. 21 3月, 2015 1 次提交
  16. 07 1月, 2015 1 次提交
  17. 19 12月, 2014 1 次提交
  18. 10 12月, 2014 1 次提交
  19. 25 11月, 2014 1 次提交
  20. 26 10月, 2014 3 次提交
    • D
      xen-netback: reintroduce guest Rx stall detection · ecf08d2d
      David Vrabel 提交于
      If a frontend not receiving packets it is useful to detect this and
      turn off the carrier so packets are dropped early instead of being
      queued and drained when they expire.
      
      A to-guest queue is stalled if it doesn't have enough free slots for a
      an extended period of time (default 60 s).
      
      If at least one queue is stalled, the carrier is turned off (in the
      expectation that the other queues will soon stall as well).  The
      carrier is only turned on once all queues are ready.
      
      When the frontend connects, all the queues start in the stalled state
      and only become ready once the frontend queues enough Rx requests.
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ecf08d2d
    • D
      xen-netback: fix unlimited guest Rx internal queue and carrier flapping · f48da8b1
      David Vrabel 提交于
      Netback needs to discard old to-guest skb's (guest Rx queue drain) and
      it needs detect guest Rx stalls (to disable the carrier so packets are
      discarded earlier), but the current implementation is very broken.
      
      1. The check in hard_start_xmit of the slot availability did not
         consider the number of packets that were already in the guest Rx
         queue.  This could allow the queue to grow without bound.
      
         The guest stops consuming packets and the ring was allowed to fill
         leaving S slot free.  Netback queues a packet requiring more than S
         slots (ensuring that the ring stays with S slots free).  Netback
         queue indefinately packets provided that then require S or fewer
         slots.
      
      2. The Rx stall detection is not triggered in this case since the
         (host) Tx queue is not stopped.
      
      3. If the Tx queue is stopped and a guest Rx interrupt occurs, netback
         will consider this an Rx purge event which may result in it taking
         the carrier down unnecessarily.  It also considers a queue with
         only 1 slot free as unstalled (even though the next packet might
         not fit in this).
      
      The internal guest Rx queue is limited by a byte length (to 512 Kib,
      enough for half the ring).  The (host) Tx queue is stopped and started
      based on this limit.  This sets an upper bound on the amount of memory
      used by packets on the internal queue.
      
      This allows the estimatation of the number of slots for an skb to be
      removed (it wasn't a very good estimate anyway).  Instead, the guest
      Rx thread just waits for enough free slots for a maximum sized packet.
      
      skbs queued on the internal queue have an 'expires' time (set to the
      current time plus the drain timeout).  The guest Rx thread will detect
      when the skb at the head of the queue has expired and discard expired
      skbs.  This sets a clear upper bound on the length of time an skb can
      be queued for.  For a guest being destroyed the maximum time needed to
      wait for all the packets it sent to be dropped is still the drain
      timeout (10 s) since it will not be sending new packets.
      
      Rx stall detection is reintroduced in a later commit.
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f48da8b1
    • D
      xen-netback: make feature-rx-notify mandatory · bc96f648
      David Vrabel 提交于
      Frontends that do not provide feature-rx-notify may stall because
      netback depends on the notification from frontend to wake the guest Rx
      thread (even if can_queue is false).
      
      This could be fixed but feature-rx-notify was introduced in 2006 and I
      am not aware of any frontends that do not implement this.
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc96f648
  21. 06 10月, 2014 1 次提交
  22. 14 8月, 2014 2 次提交
  23. 09 7月, 2014 1 次提交
    • Z
      xen-netback: Adding debugfs "io_ring_qX" files · f51de243
      Zoltan Kiss 提交于
      This patch adds debugfs capabilities to netback. There used to be a similar
      patch floating around for classic kernel, but it used procfs. It is based on a
      very similar blkback patch.
      It creates xen-netback/[vifname]/io_ring_q[queueno] files, reading them output
      various ring variables etc. Writing "kick" into it imitates an interrupt
      happened, it can be useful to check whether the ring is just stalled due to a
      missed interrupt.
      Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: xen-devel@lists.xenproject.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f51de243
  24. 26 6月, 2014 1 次提交
    • W
      xen-netback: bookkeep number of active queues in our own module · f7b50c4e
      Wei Liu 提交于
      The original code uses netdev->real_num_tx_queues to bookkeep number of
      queues and invokes netif_set_real_num_tx_queues to set the number of
      queues. However, netif_set_real_num_tx_queues doesn't allow
      real_num_tx_queues to be smaller than 1, which means setting the number
      to 0 will not work and real_num_tx_queues is untouched.
      
      This is bogus when xenvif_free is invoked before any number of queues is
      allocated. That function needs to iterate through all queues to free
      resources. Using the wrong number of queues results in NULL pointer
      dereference.
      
      So we bookkeep the number of queues in xen-netback to solve this
      problem. This fixes a regression introduced by multiqueue patchset in
      3.16-rc1.
      
      There's another bug in original code that the real number of RX queues
      is never set. In current Xen multiqueue design, the number of TX queues
      and RX queues are in fact the same. We need to set the numbers of TX and
      RX queues to the same value.
      
      Also remove xenvif_select_queue and leave queue selection to core
      driver, as suggested by David Miller.
      Reported-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NWei Liu <wei.liu2@citrix.com>
      CC: Ian Campbell <ian.campbell@citrix.com>
      CC: Paul Durrant <paul.durrant@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f7b50c4e
  25. 05 6月, 2014 2 次提交
  26. 07 12月, 2013 1 次提交
  27. 18 10月, 2013 4 次提交
  28. 09 10月, 2013 1 次提交
  29. 01 10月, 2013 1 次提交
  30. 20 9月, 2013 1 次提交
    • P
      xen-netback: Don't destroy the netdev until the vif is shut down · 279f438e
      Paul Durrant 提交于
      Without this patch, if a frontend cycles through states Closing
      and Closed (which Windows frontends need to do) then the netdev
      will be destroyed and requires re-invocation of hotplug scripts
      to restore state before the frontend can move to Connected. Thus
      when udev is not in use the backend gets stuck in InitWait.
      
      With this patch, the netdev is left alone whilst the backend is
      still online and is only de-registered and freed just prior to
      destroying the vif (which is also nicely symmetrical with the
      netdev allocation and registration being done during probe) so
      no re-invocation of hotplug scripts is required.
      Signed-off-by: NPaul Durrant <paul.durrant@citrix.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Acked-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      279f438e
  31. 02 7月, 2013 1 次提交
  32. 24 5月, 2013 1 次提交
  33. 18 5月, 2013 1 次提交
    • W
      xen-netback: enable user to unload netback module · b103f358
      Wei Liu 提交于
      This patch enables user to unload netback module, which is useful when user
      wants to upgrade to a newer netback module without rebooting the host.
      
      Netfront cannot handle netback removal event. As we cannot fix all possible
      frontends we add module get / put along with vif get / put to avoid
      mis-unloading of netback. To unload netback module, user needs to shutdown all
      VMs or migrate them to another host or unplug all vifs before hand.
      Signed-off-by: NWei Liu <wei.liu2@citrix.com>
      Acked-by: Ian Campbell <ian.campbell@citrix.com>¬
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b103f358