1. 11 5月, 2017 24 次提交
  2. 04 5月, 2017 2 次提交
    • E
      mdev: Fix daemon crash on domain shutdown after reconnect · 950f1a39
      Erik Skultety 提交于
      The problem resides in virHostdevUpdateActiveMediatedDevices which gets
      called during qemuProcessReconnect. The issue here is that
      virMediatedDeviceListAdd takes a pointer to the item to be added to the
      list to which VIR_APPEND_ELEMENT is used, which also clears the pointer.
      However, in this case only the local copy of the pointer got cleared,
      leaving the original pointing to valid memory. To sum it up, during
      cleanup phase, the original pointer is freed and the daemon crashes
      basically any time it would access it.
      
      Backtrace:
      0x00007ffff3ccdeba in __strcmp_sse2_unaligned
      0x00007ffff72a444a in virMediatedDeviceListFindIndex
      0x00007ffff7241446 in virHostdevReAttachMediatedDevices
      0x00007fffc60215d9 in qemuHostdevReAttachMediatedDevices
      0x00007fffc60216dc in qemuHostdevReAttachDomainDevices
      0x00007fffc6046e6f in qemuProcessStop
      0x00007fffc6091596 in processMonitorEOFEvent
      0x00007fffc6091793 in qemuProcessEventHandler
      0x00007ffff7294bf5 in virThreadPoolWorker
      0x00007ffff7294184 in virThreadHelper
      0x00007ffff3fdc3c4 in start_thread () from /lib64/libpthread.so.0
      0x00007ffff3d269cf in clone () from /lib64/libc.so.6
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1446455
      
      (cherry picked from commit 92e30a4d)
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      950f1a39
    • E
      util: mdev: Use a local variable instead of a direct pointer access · 5d4ecee9
      Erik Skultety 提交于
      Use a local variable to hold data, rather than accessing the pointer
      after calling virMediatedDeviceListAdd (therefore VIR_APPEND_ELEMENT).
      Although not causing an issue at the moment, this change is a necessary
      prerequisite for tweaking virMediatedDeviceListAdd in a separate patch,
      which will take a reference for the source pointer (instead of pointer
      value) and will clear it along the way.
      
      (cherry picked from commit 2739a983)
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      5d4ecee9
  3. 06 4月, 2017 1 次提交
    • J
      qemu: Fix regression when hyperv/vendor_id feature is used · 04535336
      Jiri Denemark 提交于
      qemuProcessVerifyHypervFeatures is supposed to check whether all
      requested hyperv features were actually honored by QEMU/KVM. This is
      done by checking the corresponding CPUID bits reported by the virtual
      CPU. In other words, it doesn't work for string properties, such as
      VIR_DOMAIN_HYPERV_VENDOR_ID (there is no CPUID bit we could check). We
      could theoretically check all 96 bits corresponding to the vendor
      string, but luckily we don't have to check the feature at all. If QEMU
      is too old to support hyperv features, the domain won't even start.
      Otherwise, it is always supported.
      
      Without this patch, libvirt refuses to start a domain which contains
      
        <features>
          <hyperv>
            <vendor_id state='on' value='...'/>
          </hyperv>
        </features>
      
      reporting internal error: "unknown CPU feature __kvm_hv_vendor_id.
      
      This regression was introduced by commit v3.1.0-186-ge9dbe701, which
      (by fixing the virCPUDataCheckFeature condition in
      qemuProcessVerifyHypervFeatures) revealed an old bug in the feature
      verification code. It's been there ever since the verification was
      implemented by commit v1.3.3-rc1-5-g95bbe4bf, which effectively did not
      check VIR_DOMAIN_HYPERV_VENDOR_ID at all.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1439424Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      (cherry picked from commit ae102b5d)
      04535336
  4. 04 4月, 2017 1 次提交
  5. 02 4月, 2017 1 次提交
  6. 01 4月, 2017 3 次提交
  7. 31 3月, 2017 2 次提交
  8. 30 3月, 2017 5 次提交
    • M
      qemuDomainSnapshotPrepare: Don't always assume vm->def->os.loader · fa3b5107
      Michal Privoznik 提交于
      In 9e246583 a check that denies internal snapshots when pflash
      based loader is configured for the domain. However, if there's
      none and an user tries to do an internal snapshot they will
      witness daemon crash as in that case vm->def->os.loader is NULL
      and we dereference it unconditionally.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      fa3b5107
    • J
      qemu: Check non-migratable host CPU features · 385c1cc9
      Jiri Denemark 提交于
      CPU features which change their value from disabled to enabled between
      two calls to query-cpu-model-expansion (the first with no extra
      properties set and the second with 'migratable' property set to false)
      can be marked as enabled and non-migratable in qemuMonitorCPUModelInfo.
      
      Since the code consuming qemuMonitorCPUModelInfo currently ignores the
      migratable flag, this change is effectively changing the CPU model
      advertised in domain capabilities to contain all features (even those
      which block migration). And this matches what we do for QEMU older than
      2.9.0, when we detect all CPUID bits ourselves without asking QEMU.
      
      As a result of this change
      
          <cpu mode='host-model'>
            <feature name='invtsc' policy='require'/>
          </cpu>
      
      will work with all QEMU versions. Such CPU definition would be forbidden
      with QEMU >= 2.9.0 without this patch.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      385c1cc9
    • J
      qemu: Check migratable host CPU features · 91927c62
      Jiri Denemark 提交于
      If calling query-cpu-model-expansion on the 'host'/'max' CPU model with
      'migratable' property set to false succeeds, we know QEMU is able to
      tell us which features would disable migration. Thus we can mark all
      enabled features as migratable.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      91927c62
    • J
      qemuMonitorCPUModelInfo: Add support for non-migratable features · 03a6a0db
      Jiri Denemark 提交于
      QEMU is able to tell us whether a CPU feature would block migration or
      not. This patch adds support for storing such features in
      qemuMonitorCPUModelInfo.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      03a6a0db
    • R
      docs: document bhyve UEFI support · 8a91e853
      Roman Bogorodskiy 提交于
       - Add a news entry
       - Update the driver page with documentation of the new options
         and some examples
      8a91e853
  9. 29 3月, 2017 1 次提交