1. 15 3月, 2018 2 次提交
  2. 13 3月, 2018 5 次提交
  3. 12 3月, 2018 1 次提交
  4. 09 3月, 2018 11 次提交
  5. 08 3月, 2018 1 次提交
  6. 07 3月, 2018 1 次提交
    • M
      qemuDomainObjBeginJob: Don't account DESTROY job to maxQueuedJobs · c1766641
      Michal Privoznik 提交于
      When trying to destroy a domain (e.g. because we've seen EOF on
      the monitor) we try to acquire QEMU_JOB_DESTROY. However, if
      max_queued is set in qemu.conf this may fail and since our code
      doesn't count on that we will still report domain as active even
      though the qemu process is long gone. More specifically, if we've
      seen EOF on the monitor, qemuProcessHandleMonitorEOF() is called
      which sends MONITOR_EOF job to the event worker pool and
      unregisters monitor from the event loop. The worker pool calls
      processMonitorEOFEvent() which tries to set job which may fail
      due to the limit as described above.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      c1766641
  7. 22 2月, 2018 1 次提交
  8. 20 2月, 2018 2 次提交
    • D
      Fix build with GCC 8 new switch fallthrough warnings · 75f4813c
      Daniel P. Berrangé 提交于
      GCC 8 became more fussy about detecting switch
      fallthroughs. First it doesn't like it if you have
      a fallthrough attribute that is not before a case
      statement. e.g.
      
         FOO:
         BAR:
         WIZZ:
            ATTRIBUTE_FALLTHROUGH;
      
      Is unacceptable as there's no final case statement,
      so while FOO & BAR are falling through, WIZZ is
      not falling through. IOW, GCC wants us to write
      
        FOO:
        BAR:
          ATTRIBUTE_FALLTHROUGH;
        WIZZ:
      
      Second, it will report risk of fallthrough even if you
      have a case statement for every single enum value, but
      only if the switch is nested inside another switch and
      the outer case statement has no final break. This is
      is arguably valid because despite the fact that we have
      cast from "int" to the enum typedef, nothing guarantees
      that the variable we're switching on only contains values
      that have corresponding switch labels. e.g.
      
         int domstate = 87539319;
         switch ((virDomainState)domstate) {
            ...
         }
      
      will not match enum value, but also not raise any kind
      of compiler warning. So it is right to complain about
      risk of fallthrough if no default: is present.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      75f4813c
    • D
      conf: add enum constants for default controller models · a302480d
      Daniel P. Berrangé 提交于
      The controller model is slightly unusual in that the default value is
      -1, not 0. As a result the default value is not covered by any of the
      existing enum cases. This in turn means that any switch() statements
      that think they have covered all cases, will in fact not match the
      default value at all. In the qemuDomainDeviceCalculatePCIConnectFlags()
      method this has caused a serious mistake where we fallthrough from the
      SCSI controller case, to the VirtioSerial controller case, and from
      the USB controller case to the IDE controller case.
      
      By adding explicit enum constant starting at -1, we can ensure switches
      remember to handle the default case.
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      a302480d
  9. 19 2月, 2018 1 次提交
  10. 14 2月, 2018 1 次提交
  11. 13 2月, 2018 6 次提交
  12. 10 2月, 2018 2 次提交
  13. 09 2月, 2018 2 次提交
  14. 07 2月, 2018 2 次提交
  15. 06 2月, 2018 2 次提交