1. 18 7月, 2019 3 次提交
  2. 03 7月, 2019 1 次提交
  3. 21 6月, 2019 2 次提交
  4. 20 6月, 2019 1 次提交
  5. 19 6月, 2019 1 次提交
  6. 09 5月, 2019 3 次提交
  7. 10 4月, 2019 1 次提交
  8. 04 4月, 2019 2 次提交
  9. 03 4月, 2019 1 次提交
  10. 27 3月, 2019 1 次提交
  11. 22 3月, 2019 1 次提交
  12. 15 3月, 2019 1 次提交
    • M
      qemu_hotplug: Fix a rare race condition when detaching a device twice · c2bc4191
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1623389
      
      If a device is detached twice from the same domain the following
      race condition may happen:
      
      1) The first DetachDevice() call will issue "device_del" on qemu
      monitor, but since the DEVICE_DELETED event did not arrive in
      time, the API ends claiming "Device detach request sent
      successfully".
      
      2) The second DetachDevice() therefore still find the device in
      the domain and thus proceeds to detaching it again. It calls
      EnterMonitor() and qemuMonitorSend() trying to issue "device_del"
      command again. This gets both domain lock and monitor lock
      released.
      
      3) At this point, qemu sends us the DEVICE_DELETED event which is
      going to be handled by the event loop which ends up calling
      qemuDomainSignalDeviceRemoval() to determine who is going to
      remove the device from domain definition. Whether it is the
      caller that marked the device for removal or whether it is going
      to be the event processing thread.
      
      4) Because the device was marked for removal,
      qemuDomainSignalDeviceRemoval() returns true, which means the
      event is to be processed by the thread that has marked the device
      for removal (and is currently still trying to issue "device_del"
      command)
      
      5) The thread finally issues the "device_del" command, which
      fails (obviously) and therefore it calls
      qemuDomainResetDeviceRemoval() to reset the device marking and
      quits immediately after, NOT removing any device from the domain
      definition.
      
      At this point, the device is still present in the domain
      definition but doesn't exist in qemu anymore. Worse, there is no
      way to remove it from the domain definition.
      
      Solution is to note down that we've seen the event and if the
      second "device_del" fails, not take it as a failure but carry on
      with the usual execution.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      ACKed-by: NPeter Krempa <pkrempa@redhat.com>
      c2bc4191
  13. 12 3月, 2019 1 次提交
  14. 08 3月, 2019 1 次提交
  15. 08 2月, 2019 5 次提交
  16. 04 2月, 2019 1 次提交
  17. 31 1月, 2019 2 次提交
  18. 22 1月, 2019 2 次提交
  19. 18 1月, 2019 1 次提交
  20. 09 1月, 2019 1 次提交
    • 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
  21. 21 12月, 2018 1 次提交
    • N
      qemu: don't log error for missing optional storage sources on stats · 318d807a
      Nikolay Shirokovskiy 提交于
      Every time we call all domain stats for inactive domain with
      unavailable storage source we get error message in logs [1]. It's a bit noisy.
      While it's arguable whether we need such message or not for mandatory
      disks we would like not to see messages for optional disks. Let's
      filter at least for cases of local files. Fixing other cases would
      require passing flag down the stack to .backendInit of storage
      which is ugly.
      
      Stats for active domain are fine because we either drop disks
      with unavailable sources or clean source which is handled
      by virStorageSourceIsEmpty in qemuDomainGetStatsOneBlockFallback.
      
      We have these logs for successful stats since 25aa7035 (version 1.2.15)
      which in turn fixes 596a1371 (version 1.2.12 )which added substantial
      stats for offline disks.
      
      [1] error message example:
      qemuOpenFileAs:3324 : Failed to open file '/path/to/optional/disk': No such file or directory
      Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      318d807a
  22. 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
  23. 13 12月, 2018 1 次提交
    • M
      qemu: Don't use -mem-prealloc among with .prealloc=yes · c658764d
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1624223
      
      There are two ways to request memory preallocation on cmd line:
      -mem-prealloc and .prealloc attribute for a memory-backend-file.
      However, as it turns out it's not safe to use both at the same
      time. If -mem-prealloc is used then qemu will fully allocate the
      memory (this is done by actually touching every page that has
      been allocated). Then, if .prealloc=yes is specified,
      mbind(flags = MPOL_MF_STRICT | MPOL_MF_MOVE) is called which:
      
      a) has to (possibly) move the memory to a different NUMA node,
      b) can have no effect when hugepages are in play (thus ignoring user
      request to place memory on desired NUMA nodes).
      
      Prefer -mem-prealloc as it is more backward compatible
      compared to switching to "-numa node,memdev=  + -object
      memory-backend-file".
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      c658764d
  24. 16 11月, 2018 1 次提交
    • M
      qemu_domain: Track if domain remembers original owner · 7a44ffa6
      Michal Privoznik 提交于
      For metadata locking we might need an extra fork() which given
      latest attempts to do fewer fork()-s is suboptimal. Therefore,
      there will be a qemu.conf knob to {en|dis}able this feature. But
      since the feature is actually not metadata locking itself rather
      than remembering of the original owner of the file this is named
      as 'rememberOwner'. But patches for that feature are not even
      posted yet so there is actually no qemu.conf entry in this patch
      nor a way to enable this feature.
      
      Even though this is effectively a dead code for now it is still
      desired.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      7a44ffa6
  25. 12 11月, 2018 1 次提交
  26. 07 11月, 2018 1 次提交
    • J
      qemu: Restore lost shutdown reason · 296e05b5
      John Ferlan 提交于
      When qemuProcessReconnectHelper was introduced (commit d38897a5)
      reconnection failure used VIR_DOMAIN_SHUTOFF_FAILED; however, that
      was changed in commit bda2f17d to either VIR_DOMAIN_SHUTOFF_CRASHED
      or VIR_DOMAIN_SHUTOFF_UNKNOWN.
      
      When QEMU_CAPS_NO_SHUTDOWN checking was removed in commit fe35b1ad
      the conditional state was just left at VIR_DOMAIN_SHUTOFF_CRASHED.
      
      So introduce qemuDomainIsUsingNoShutdown which will manage the
      condition when the domain was started with -no-shutdown so that
      when/if reconnection failure occurs we can restore the decision
      point used to determine whether CRASHED or UNKNOWN is provided.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
      296e05b5
  27. 02 10月, 2018 1 次提交