1. 09 10月, 2019 5 次提交
    • M
      Revert "qemu: Obtain reference on monConfig" · 8e4aa7c5
      Michal Privoznik 提交于
      This reverts commit a5a777a8.
      
      After previous commit the domain won't disappear while connecting
      to monitor. There's no need to ref monitor config then.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      8e4aa7c5
    • M
      qemu: Fix @vm locking issue when connecting to the monitor · 75dd5958
      Michal Privoznik 提交于
      When connecting to qemu's monitor the @vm object is unlocked.
      This is justified - connecting may take a long time and we don't
      want to wait with the domain object locked. However, just before
      the domain object is locked again, the monitor's FD is registered
      in the event loop. Therefore, there is a small window where the
      event loop has a chance to call a handler for an event that
      occurred on the monitor FD but vm is not initalized properly just
      yet (i.e. priv->mon is not set). For instance, if there's an
      incoming migration, qemu creates its socket but then fails to
      initialize (for various reasons, I'm reproducing this by using
      hugepages but leaving the HP pool empty) then the following may
      happen:
      
      1) qemuConnectMonitor() unlocks @vm
      
      2) qemuMonitorOpen() connects to the monitor socket and by
         calling qemuMonitorOpenInternal() which subsequently calls
         qemuMonitorRegister() the event handler is installed
      
      3) qemu fails to initialize and exit()-s, which closes the
         monitor
      
      4) The even loop sees EOF on the monitor and the control gets to
         qemuProcessEventHandler() which locks @vm and calls
         processMonitorEOFEvent() which then calls
         qemuMonitorLastError(priv->mon). But priv->mon is not set just
         yet.
      
      5) qemuMonitorLastError() dereferences NULL pointer
      
      The solution is to unlock the domain object for a shorter time
      and most importantly, register event handler with domain object
      locked so that any possible event processing is done only after
      @vm's private data was properly initialized.
      
      This issue is also mentioned in v4.2.0-99-ga5a777a8.
      
      Since we are unlocking @vm and locking it back, another thread
      might have destroyed the domain meanwhile. Therefore we have to
      check if domain is still active, and we have to do it at the
      same place where domain lock is acquired back, i.e. in
      qemuMonitorOpen(). This creates a small problem for our test
      suite which calls qemuMonitorOpen() directly and passes @vm which
      has no definition. This makes virDomainObjIsActive() call crash.
      Fortunately, allocating empty domain definition is sufficient.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      75dd5958
    • J
      qemu: Adapt to changed ppc64 CPU model names · db873ab3
      Jiri Denemark 提交于
      QEMU 2.11 for ppc64 changed all CPU model names to lower case. Since
      libvirt can't change the model names for compatibility reasons, we need
      to translate the matching lower case models to the names known by
      libvirt.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      db873ab3
    • J
      Revert "domcaps: Treat host models as case-insensitive strings" · b979ec35
      Jiri Denemark 提交于
      This reverts commit 2d8721e2.
      
      This fix was both incomplete and too general. It only fixed domain
      startup, but libvirt would still report empty list of supported CPU
      models with recent QEMU for ppc64. On the other hand, while ppc64 QEMU
      ignores case when looking up CPU model names, x86_64 QEMU does case
      sensitive lookup. Without reverting this patch, libvirt could happily
      accept CPU model names which are not supported by QEMU.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      b979ec35
    • D
      build: stop clang complaining about redefined typedefs · 412cc0f4
      Daniel P. Berrangé 提交于
      Clang's gnu99 mode is not quite the same as GCC's. It will complain
      about redefined typedefs being a C11 feature, while GCC does not
      complain and allows them in gnu99 mode.
      Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      412cc0f4
  2. 08 10月, 2019 6 次提交
  3. 07 10月, 2019 29 次提交