1. 07 Mar, 2014 2 commits
    • Zoltan Kiss's avatar
      xen-netback: Introduce TX grant mapping · f53c3fe8
      Zoltan Kiss authored
      
      
      This patch introduces grant mapping on netback TX path. It replaces grant copy
      operations, ditching grant copy coalescing along the way. Another solution for
      copy coalescing is introduced in "xen-netback: Handle guests with too many
      frags", older guests and Windows can broke before that patch applies.
      There is a callback (xenvif_zerocopy_callback) from core stack to release the
      slots back to the guests when kfree_skb or skb_orphan_frags called. It feeds a
      separate dealloc thread, as scheduling NAPI instance from there is inefficient,
      therefore we can't do dealloc from the instance.
      
      Signed-off-by: default avatarZoltan Kiss <zoltan.kiss@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f53c3fe8
    • Zoltan Kiss's avatar
      xen-netback: Minor refactoring of netback code · 121fa4b7
      Zoltan Kiss authored
      
      
      This patch contains a few bits of refactoring before introducing the grant
      mapping changes:
      - introducing xenvif_tx_pending_slots_available(), as this is used several
        times, and will be used more often
      - rename the thread to vifX.Y-guest-rx, to signify it does RX work from the
        guest point of view
      
      Signed-off-by: default avatarZoltan Kiss <zoltan.kiss@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      121fa4b7
  2. 06 Feb, 2014 1 commit
    • Zoltan Kiss's avatar
      xen-netback: Fix Rx stall due to race condition · 9ab9831b
      Zoltan Kiss authored
      The recent patch to fix receive side flow control
      (11b57f90
      
      : xen-netback: stop vif thread
      spinning if frontend is unresponsive) solved the spinning thread problem,
      however caused an another one. The receive side can stall, if:
      - [THREAD] xenvif_rx_action sets rx_queue_stopped to true
      - [INTERRUPT] interrupt happens, and sets rx_event to true
      - [THREAD] then xenvif_kthread sets rx_event to false
      - [THREAD] rx_work_todo doesn't return true anymore
      
      Also, if interrupt sent but there is still no room in the ring, it take quite a
      long time until xenvif_rx_action realize it. This patch ditch that two variable,
      and rework rx_work_todo. If the thread finds it can't fit more skb's into the
      ring, it saves the last slot estimation into rx_last_skb_slots, otherwise it's
      kept as 0. Then rx_work_todo will check if:
      - there is something to send to the ring (like before)
      - there is space for the topmost packet in the queue
      
      I think that's more natural and optimal thing to test than two bool which are
      set somewhere else.
      
      Signed-off-by: default avatarZoltan Kiss <zoltan.kiss@citrix.com>
      Reviewed-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ab9831b
  3. 06 Jan, 2014 1 commit
  4. 30 Dec, 2013 1 commit
    • Paul Durrant's avatar
      xen-netback: fix guest-receive-side array sizes · ac3d5ac2
      Paul Durrant authored
      
      
      The sizes chosen for the metadata and grant_copy_op arrays on the guest
      receive size are wrong;
      
      - The meta array is needlessly twice the ring size, when we only ever
        consume a single array element per RX ring slot
      - The grant_copy_op array is way too small. It's sized based on a bogus
        assumption: that at most two copy ops will be used per ring slot. This
        may have been true at some point in the past but it's clear from looking
        at start_new_rx_buffer() that a new ring slot is only consumed if a frag
        would overflow the current slot (plus some other conditions) so the actual
        limit is MAX_SKB_FRAGS grant_copy_ops per ring slot.
      
      This patch fixes those two sizing issues and, because grant_copy_ops grows
      so much, it pulls it out into a separate chunk of vmalloc()ed memory.
      
      Signed-off-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ac3d5ac2
  5. 10 Dec, 2013 1 commit
    • Paul Durrant's avatar
      xen-netback: improve guest-receive-side flow control · ca2f09f2
      Paul Durrant authored
      
      
      The way that flow control works without this patch is that, in start_xmit()
      the code uses xenvif_count_skb_slots() to predict how many slots
      xenvif_gop_skb() will consume and then adds this to a 'req_cons_peek'
      counter which it then uses to determine if the shared ring has that amount
      of space available by checking whether 'req_prod' has passed that value.
      If the ring doesn't have space the tx queue is stopped.
      xenvif_gop_skb() will then consume slots and update 'req_cons' and issue
      responses, updating 'rsp_prod' as it goes. The frontend will consume those
      responses and post new requests, by updating req_prod. So, req_prod chases
      req_cons which chases rsp_prod, and can never exceed that value. Thus if
      xenvif_count_skb_slots() ever returns a number of slots greater than
      xenvif_gop_skb() uses, req_cons_peek will get to a value that req_prod cannot
      possibly achieve (since it's limited by the 'real' req_cons) and, if this
      happens enough times, req_cons_peek gets more than a ring size ahead of
      req_cons and the tx queue then remains stopped forever waiting for an
      unachievable amount of space to become available in the ring.
      
      Having two routines trying to calculate the same value is always going to be
      fragile, so this patch does away with that. All we essentially need to do is
      make sure that we have 'enough stuff' on our internal queue without letting
      it build up uncontrollably. So start_xmit() makes a cheap optimistic check
      of how much space is needed for an skb and only turns the queue off if that
      is unachievable. net_rx_action() is the place where we could do with an
      accurate predicition but, since that has proven tricky to calculate, a cheap
      worse-case (but not too bad) estimate is all we really need since the only
      thing we *must* prevent is xenvif_gop_skb() consuming more slots than are
      available.
      
      Without this patch I can trivially stall netback permanently by just doing
      a large guest to guest file copy between two Windows Server 2008R2 VMs on a
      single host.
      
      Patch tested with frontends in:
      - Windows Server 2008R2
      - CentOS 6.0
      - Debian Squeeze
      - Debian Wheezy
      - SLES11
      
      Signed-off-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Annie Li <annie.li@oracle.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ca2f09f2
  6. 03 Dec, 2013 1 commit
    • Paul Durrant's avatar
      xen-netback: clear vif->task on disconnect · 67fa3660
      Paul Durrant authored
      xenvif_start_xmit() relies on checking vif->task for NULL to determine
      whether the vif is ready to accept packets. The task thread is stopped in
      xenvif_disconnect() but task is not set to NULL. Thus, on a re-connect the
      check will give a false positive.
      
      Also since commit ea732dff
      
       (Handle backend
      state transitions in a more robust way) it should not be possible for
      xenvif_connect() to be called if the vif is already connected so change the
      check of vif->tx_irq to a BUG_ON() and also add a BUG_ON(vif->task).
      
      Signed-off-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      67fa3660
  7. 21 Nov, 2013 1 commit
  8. 29 Oct, 2013 1 commit
  9. 17 Oct, 2013 3 commits
  10. 19 Sep, 2013 1 commit
    • Paul Durrant's avatar
      xen-netback: Don't destroy the netdev until the vif is shut down · 279f438e
      Paul Durrant authored
      
      
      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: default avatarPaul 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: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      279f438e
  11. 12 Sep, 2013 1 commit
  12. 29 Aug, 2013 2 commits
  13. 24 May, 2013 1 commit
  14. 18 May, 2013 1 commit
  15. 14 Feb, 2013 1 commit
  16. 08 Feb, 2013 1 commit
    • Ian Campbell's avatar
      xen/netback: shutdown the ring if it contains garbage. · 48856286
      Ian Campbell authored
      
      
      A buggy or malicious frontend should not be able to confuse netback.
      If we spot anything which is not as it should be then shutdown the
      device and don't try to continue with the ring in a potentially
      hostile state. Well behaved and non-hostile frontends will not be
      penalised.
      
      As well as making the existing checks for such errors fatal also add a
      new check that ensures that there isn't an insane number of requests
      on the ring (i.e. more than would fit in the ring). If the ring
      contains garbage then previously is was possible to loop over this
      insane number, getting an error each time and therefore not generating
      any more pending requests and therefore not exiting the loop in
      xen_netbk_tx_build_gops for an externded period.
      
      Also turn various netdev_dbg calls which no precipitate a fatal error
      into netdev_err, they are rate limited because the device is shutdown
      afterwards.
      
      This fixes at least one known DoS/softlockup of the backend domain.
      
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarJan Beulich <JBeulich@suse.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48856286
  17. 23 Jan, 2013 1 commit
  18. 05 Jan, 2012 1 commit
  19. 16 Nov, 2011 1 commit
  20. 03 Oct, 2011 1 commit
  21. 20 Apr, 2011 1 commit
  22. 16 Mar, 2011 1 commit
    • Ian Campbell's avatar
      xen network backend driver · f942dc25
      Ian Campbell authored
      netback is the host side counterpart to the frontend driver in
      drivers/net/xen-netfront.c. The PV protocol is also implemented by
      frontend drivers in other OSes too, such as the BSDs and even Windows.
      
      The patch is based on the driver from the xen.git pvops kernel tree but
      has been put through the checkpatch.pl wringer plus several manual
      cleanup passes and review iterations. The driver has been moved from
      drivers/xen/netback to drivers/net/xen-netback.
      
      One major change from xen.git is that the guest transmit path (i.e. what
      looks like receive to netback) has been significantly reworked to remove
      the dependency on the out of tree PageForeign page flag (a core kernel
      patch which enables a per page destructor callback on the final
      put_page). This page flag was used in order to implement a grant map
      based transmit path (where guest pages are mapped directly into SKB
      frags). Instead this version of netback uses grant copy operations into
      regular memory belonging to the backend domain. Reinstating the grant
      map functionality is something which I would like to revisit in the
      future.
      
      Note that this driver depends on 2e820f58 "xen/irq: implement
      bind_interdomain_evtchn_to_irqhandler for backend drivers" which is in
      linux next via the "xen-two" tree and is intended for the 2.6.39 merge
      window:
              git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
      
       stable/backends
      this branch has only that single commit since 2.6.38-rc2 and is safe for
      cross merging into the net branch.
      
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f942dc25