1. 20 6月, 2019 2 次提交
  2. 12 6月, 2019 4 次提交
  3. 21 5月, 2019 2 次提交
  4. 25 4月, 2019 1 次提交
  5. 26 3月, 2019 2 次提交
  6. 15 3月, 2019 1 次提交
  7. 04 2月, 2019 3 次提交
  8. 09 1月, 2019 2 次提交
    • M
      qemu: Use ULL instead of uint64_t for RDMA GID event · f8862714
      Michal Privoznik 提交于
      In the previous commit we are using uint64_t for storing subnet
      prefix and interface id that qemu reports in
      RDMA_GID_STATUS_CHANGED event. We also report them in some debug
      messages. This poses a problem because uint64_t can be UL or ULL
      depending on the host architecture and hence we wouldn't know
      which format to use. Switch to ULL which is big enough and
      doesn't suffer from the issue.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      f8862714
    • Y
      qemu: Process RDMA GID state change event · ed357cef
      Yuval Shaia 提交于
      This event is emitted on the monitor when a GID table in pvrdma device
      is modified and the change needs to be propagate to the backend RDMA
      device's GID table.
      
      The control over the RDMA device's GID table is done by updating the
      device's Ethernet function addresses.
      Usually the first GID entry is determine by the MAC address, the second
      by the first IPv6 address and the third by the IPv4 address. Other
      entries can be added by adding more IP addresses. The opposite is the
      same, i.e. whenever an address is removed, the corresponding GID entry
      is removed.
      
      The process is done by the network and RDMA stacks. Whenever an address
      is added the ib_core driver is notified and calls the device driver's
      add_gid function which in turn update the device.
      
      To support this in pvrdma device we need to hook into the create_bind
      and destroy_bind HW commands triggered by pvrdma driver in guest.
      Whenever a changed is made to the pvrdma device's GID table a special
      QMP messages is sent to be processed by libvirt to update the address of
      the backend Ethernet device.
      Signed-off-by: NYuval Shaia <yuval.shaia@oracle.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      ed357cef
  9. 14 12月, 2018 2 次提交
    • D
      Enforce a standard header file guard symbol name · 568a4172
      Daniel P. Berrangé 提交于
      Require that all headers are guarded by a symbol named
      
        LIBVIRT_$FILENAME
      
      where $FILENAME is the uppercased filename, with all characters
      outside a-z changed into '_'.
      
      Note we do not use a leading __ because that is technically a
      namespace reserved for the toolchain.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      568a4172
    • D
      Remove all Author(s): lines from source file headers · 60046283
      Daniel P. Berrangé 提交于
      In many files there are header comments that contain an Author:
      statement, supposedly reflecting who originally wrote the code.
      In a large collaborative project like libvirt, any non-trivial
      file will have been modified by a large number of different
      contributors. IOW, the Author: comments are quickly out of date,
      omitting people who have made significant contribitions.
      
      In some places Author: lines have been added despite the person
      merely being responsible for creating the file by moving existing
      code out of another file. IOW, the Author: lines give an incorrect
      record of authorship.
      
      With this all in mind, the comments are useless as a means to identify
      who to talk to about code in a particular file. Contributors will always
      be better off using 'git log' and 'git blame' if they need to  find the
      author of a particular bit of code.
      
      This commit thus deletes all Author: comments from the source and adds
      a rule to prevent them reappearing.
      
      The Copyright headers are similarly misleading and inaccurate, however,
      we cannot delete these as they have legal meaning, despite being largely
      inaccurate. In addition only the copyright holder is permitted to change
      their respective copyright statement.
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      60046283
  10. 05 12月, 2018 1 次提交
  11. 19 11月, 2018 1 次提交
    • J
      qemu: Add monitor functions to set IOThread params · 3083bf18
      John Ferlan 提交于
      Add functions to set the IOThreadInfo param data for the live guest.
      Modify the _qemuMonitorIOThreadInfo to have a flag to indicate when
      a value was set so that we don't set a value unless it was desired
      to be set.
      
      Based on code originally posted by Pavel Hrdina <phrdina@redhat.com>,
      but extracted into a separate patch. Note that qapi expects to receive
      integer parameters rather than unsigned long long or unsigned int's.
      QEMU does save the value in larger signed 64 bit values eventually.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
      3083bf18
  12. 17 9月, 2018 1 次提交
  13. 24 8月, 2018 2 次提交
  14. 21 8月, 2018 8 次提交
  15. 23 7月, 2018 1 次提交
    • A
      src: Make virStr*cpy*() functions return an int · 6c0d0210
      Andrea Bolognani 提交于
      Currently, the functions return a pointer to the
      destination buffer on success or NULL on failure.
      
      Not only does this kind of error handling look quite
      alien in the context of libvirt, where most functions
      return zero on success and a negative int on failure,
      but it's also somewhat pointless because unless there's
      been a failure the returned pointer will be the same
      one passed in by the user, thus offering no additional
      value.
      
      Change the functions so that they return an int
      instead.
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      6c0d0210
  16. 20 7月, 2018 2 次提交
  17. 10 7月, 2018 3 次提交
  18. 22 6月, 2018 1 次提交
    • W
      qemu: fix msg could be a wild pointer in qemuMonitorIOProcess() · f92d164c
      Weilun Zhu 提交于
      As qemuMonitorJSONIOProcess will call qemuMonitorJSONIOProcessEvent
      which unlocks the monitor mutex, there is some extreme situation,
      eg qemu send message to monitor twice in a short time, where the
      local viriable 'msg' of qemuMonitorIOProcess could be a wild point:
      
      1. qemuMonitorSend() assign mon->msg to parameter 'msg', which is alse a
      local variable of its caller qemuMonitorJSONCommandWithFd(), cause
      eventloop to send message to monitor, then wait condition.
      2. qemu send message to monitor for the first time immediately.
      3. qemuMonitorIOProcess() is called, then wake up the qemuMonitorSend()
      thread, but the qemuMonitorSend() thread stuck for a while as cpu pressure
      or some other reasons, which means the qemu monitor is still unlocked.
      4. qemu send event message to monitor for the second time,
      such as RTC_CHANGE event
      5. qemuMonitorIOProcess() is called again, the local viriable 'msg' is
      assigned to mon->msg.
      6. qemuMonitorIOProcess() call qemuMonitorJSONIOProcess() to deal with
      the qemu event.
      7. qemuMonitorJSONIOProcess() unlock the qemu monitor in the macro
      'QEMU_MONITOR_CALLBACK', then qemuMonitorSend() thread get the mutex
      and free the mon->msg, assign mon->msg to NULL.
      Signed-off-by: NWeilun Zhu <zhuweilun@huawei.com>
      Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
      f92d164c
  19. 19 6月, 2018 1 次提交
    • J
      qemu: Fix qemuMonitorCreateObjectProps · d43cedcb
      John Ferlan 提交于
      Fix the return value status comparison checking for call to
      virJSONValueObjectCreateVArgs introduced by commit id f0a23c0c.
      
      If a NULL arglist is passed, then a 0 is returned which is a
      valid status and we only should fail when the return is < 0.
      
      This resolves an issue seen for "virsh iothreadadd $dom $iothread"
      where a "error: An error occurred, but the cause is unknown" error
      was generated when trying to hotplug an IOThread to a domain since
      qemuDomainHotplugAddIOThread passes a NULL arglist.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      d43cedcb