1. 02 5月, 2017 2 次提交
  2. 04 4月, 2017 1 次提交
  3. 24 3月, 2017 1 次提交
  4. 23 3月, 2017 1 次提交
  5. 14 3月, 2017 1 次提交
  6. 02 3月, 2017 2 次提交
  7. 27 2月, 2017 1 次提交
  8. 25 2月, 2017 1 次提交
  9. 15 2月, 2017 2 次提交
  10. 14 2月, 2017 3 次提交
  11. 10 2月, 2017 3 次提交
    • J
      xen: optimize xenbus driver for multiple concurrent xenstore accesses · fd8aa909
      Juergen Gross 提交于
      Handling of multiple concurrent Xenstore accesses through xenbus driver
      either from the kernel or user land is rather lame today: xenbus is
      capable to have one access active only at one point of time.
      
      Rewrite xenbus to handle multiple requests concurrently by making use
      of the request id of the Xenstore protocol. This requires to:
      
      - Instead of blocking inside xb_read() when trying to read data from
        the xenstore ring buffer do so only in the main loop of
        xenbus_thread().
      
      - Instead of doing writes to the xenstore ring buffer in the context of
        the caller just queue the request and do the write in the dedicated
        xenbus thread.
      
      - Instead of just forwarding the request id specified by the caller of
        xenbus to xenstore use a xenbus internal unique request id. This will
        allow multiple outstanding requests.
      
      - Modify the locking scheme in order to allow multiple requests being
        active in parallel.
      
      - Instead of waiting for the reply of a user's xenstore request after
        writing the request to the xenstore ring buffer return directly to
        the caller and do the waiting in the read path.
      
      Additionally signal handling was optimized by avoiding waking up the
      xenbus thread or sending an event to Xenstore in case the addressed
      entity is known to be running already.
      
      As a result communication with Xenstore is sped up by a factor of up
      to 5: depending on the request type (read or write) and the amount of
      data transferred the gain was at least 20% (small reads) and went up to
      a factor of 5 for large writes.
      
      In the end some more rough edges of xenbus have been smoothed:
      
      - Handling of memory shortage when reading from xenstore ring buffer in
        the xenbus driver was not optimal: it was busy looping and issuing a
        warning in each loop.
      
      - In case of xenstore not running in dom0 but in a stubdom we end up
        with two xenbus threads running as the initialization of xenbus in
        dom0 expecting a local xenstored will be redone later when connecting
        to the xenstore domain. Up to now this was no problem as locking
        would prevent the two xenbus threads interfering with each other, but
        this was just a waste of kernel resources.
      
      - An out of memory situation while writing to or reading from the
        xenstore ring buffer no longer will lead to a possible loss of
        synchronization with xenstore.
      
      - The user read and write part are now interruptible by signals.
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      fd8aa909
    • J
      xen: modify xenstore watch event interface · 5584ea25
      Juergen Gross 提交于
      Today a Xenstore watch event is delivered via a callback function
      declared as:
      
      void (*callback)(struct xenbus_watch *,
                       const char **vec, unsigned int len);
      
      As all watch events only ever come with two parameters (path and token)
      changing the prototype to:
      
      void (*callback)(struct xenbus_watch *,
                       const char *path, const char *token);
      
      is the natural thing to do.
      
      Apply this change and adapt all users.
      
      Cc: konrad.wilk@oracle.com
      Cc: roger.pau@citrix.com
      Cc: wei.liu2@citrix.com
      Cc: paul.durrant@citrix.com
      Cc: netdev@vger.kernel.org
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Reviewed-by: NPaul Durrant <paul.durrant@citrix.com>
      Reviewed-by: NWei Liu <wei.liu2@citrix.com>
      Reviewed-by: NRoger Pau Monné <roger.pau@citrix.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      5584ea25
    • J
      xen: clean up xenbus internal headers · 332f791d
      Juergen Gross 提交于
      The xenbus driver has an awful mixture of internally and globally
      visible headers: some of the internally used only stuff is defined in
      the global header include/xen/xenbus.h while some stuff defined in
      internal headers is used by other drivers, too.
      
      Clean this up by moving the externally used symbols to
      include/xen/xenbus.h and the symbols used internally only to a new
      header drivers/xen/xenbus/xenbus.h replacing xenbus_comms.h and
      xenbus_probe.h
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      332f791d
  12. 08 2月, 2017 1 次提交
  13. 07 2月, 2017 3 次提交
  14. 04 2月, 2017 1 次提交
  15. 20 1月, 2017 1 次提交
  16. 14 1月, 2017 1 次提交
  17. 07 1月, 2017 1 次提交
  18. 04 1月, 2017 1 次提交
  19. 03 1月, 2017 1 次提交
  20. 25 12月, 2016 1 次提交
  21. 24 12月, 2016 3 次提交
  22. 22 12月, 2016 1 次提交
  23. 19 12月, 2016 1 次提交
  24. 15 12月, 2016 1 次提交
  25. 12 12月, 2016 2 次提交
  26. 10 12月, 2016 1 次提交
  27. 08 12月, 2016 2 次提交