1. 12 10月, 2016 5 次提交
    • G
      xhci: use linked list for transfers · 94b037f2
      Gerd Hoffmann 提交于
      xhci has a fixed number of 24 (TD_QUEUE) XHCITransfer structs per
      endpoint, which turns out to be a problem for usb3 devices with 32 (or
      more) bulk streams.  xhci re-checks the trb rings on every finished
      transfer to make sure it'll pick up any pending work.  But that scheme
      breaks in case the first transfer of a ring can't be started because we
      ran out of XHCITransfer structs already.
      
      So remove static XHCITransfer array from XHCIEPContext.  Use a linked
      list instead, and allocate/free XHCITransfer as needed.  Add helper
      functions to allocate & initialize and to cleanup & release
      XHCITransfer structs.  That also simplifies trb management, we never
      have to realloc XHCITransfer->trbs because we don't reuse XHCITransfer
      structs any more.
      
      New dynamic limit for in-flight xhci transfers per endpoint is
      number-of-streams + 16.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Message-id: 1474965172-30321-5-git-send-email-kraxel@redhat.com
      94b037f2
    • G
      xhci: drop unused comp_xfer field · 7512b13d
      Gerd Hoffmann 提交于
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Message-id: 1474965172-30321-4-git-send-email-kraxel@redhat.com
      7512b13d
    • G
      xhci: decouple EV_QUEUE from TD_QUEUE · 1fe163fe
      Gerd Hoffmann 提交于
      EV_QUEUE must not change because an array of that size is part of live
      migration data.  Hard-code current value there, so we can touch TD_QUEUE
      without breaking live migration.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Message-id: 1474965172-30321-3-git-send-email-kraxel@redhat.com
      1fe163fe
    • G
      xhci: limit the number of link trbs we are willing to process · 05f43d44
      Gerd Hoffmann 提交于
      Needed to avoid we run in circles forever in case the guest builds
      an endless loop with link trbs.
      Reported-by: NLi Qiang <liqiang6-s@360.cn>
      Tested-by: NP J P <ppandit@redhat.com>
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Message-id: 1476096382-7981-1-git-send-email-kraxel@redhat.com
      05f43d44
    • E
      build: Work around SIZE_MAX bug in OSX headers · 6b39b063
      Eric Blake 提交于
      C99 requires SIZE_MAX to be declared with the same type as the
      integral promotion of size_t, but OSX mistakenly defines it as
      an 'unsigned long long' expression even though size_t is only
      'unsigned long'.  Rather than futzing around with whether size_t
      is 32- or 64-bits wide (which would be needed if we cared about
      using SIZE_T in a #if expression), just hard-code it with a cast.
      This is not a strict C99-compliant definition, because it doesn't
      work in the preprocessor, but if we later need that, the build
      will break on Mac to inform us to improve our replacement at that
      time.
      
      See also https://patchwork.ozlabs.org/patch/542327/ for an
      instance where the wrong type trips us up if we don't fix it
      for good in osdep.h.
      
      Some versions of glibc make a similar mistake with SSIZE_MAX; the
      goal is that the approach of this patch could be copied to work
      around that problem if it ever becomes important to us.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Message-id: 1476200784-17210-1-git-send-email-eblake@redhat.com
      Reviewed-by: NJohn Arbuckle <programmingkidx@gmail.com>
      Tested-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      6b39b063
  2. 10 10月, 2016 35 次提交