1. 17 5月, 2019 3 次提交
    • A
      tests: Refresh capabilities for QEMU on ppc64 · 35e4c153
      Andrea Bolognani 提交于
      Now that we're probing machine type properties using the
      latest machine type rather than the "spapr-machine" parent,
      we can finally discover properties that are not available
      on all machine types.
      
      This commit refreshes replies for QEMU 4.0.0 as well as
      3.1.0 to show not only that we're actually discovering new
      machine type properties this way, but also that the number
      of available machine type properties increases with each
      subsequent QEMU release.
      
      If qom-list-properties had been available in QEMU 2.10.0,
      we could now drop the explicit version number checks for
      the QEMU_CAPS_MACHINE_PSERIES_MAX_CPU_COMPAT and
      QEMU_CAPS_MACHINE_PSERIES_RESIZE_HPT capabilities, but
      unfortunately it wasn't, so we have to keep them around
      still.
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      35e4c153
    • A
      qemu: Probe canonicalized machine type · d22c6221
      Andrea Bolognani 提交于
      Now that we have the list of machine types available when
      probing machine type properties, we can list properties for
      the canonicalized version of the "pseries" machine type
      instead of having to go through "spapr-machine", which we
      know to be the parent type for all "pseries-*-machine"
      types. By doing this, we'll be able to find even properties
      that are only available from a certain versioned machine
      type forward, and can't thus be obtained when looking at
      the parent type only.
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      d22c6221
    • A
      qemu: Move call to virQEMUCapsProbeQMPMachineProps() · 295a42e1
      Andrea Bolognani 提交于
      We're going to need information about available machine types
      when probing machine type properties soon, and that means we
      have to change the order we call QMP commands.
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      295a42e1
  2. 06 5月, 2019 1 次提交
  3. 08 2月, 2019 3 次提交
  4. 28 11月, 2018 1 次提交
  5. 16 11月, 2018 1 次提交
  6. 07 9月, 2018 1 次提交
  7. 24 8月, 2018 2 次提交
  8. 26 6月, 2018 2 次提交
  9. 12 6月, 2018 1 次提交
  10. 14 5月, 2018 1 次提交
  11. 22 3月, 2018 1 次提交
  12. 08 3月, 2018 1 次提交
  13. 08 11月, 2017 2 次提交
  14. 21 7月, 2017 2 次提交
  15. 15 5月, 2017 1 次提交
  16. 27 4月, 2017 1 次提交
  17. 30 3月, 2017 1 次提交
  18. 21 3月, 2017 1 次提交
  19. 04 3月, 2017 3 次提交
    • J
      qemu: Use full CPU model expansion on x86 · bb3363c9
      Jiri Denemark 提交于
      The static CPU model expansion is designed to return only canonical
      names of all CPU properties. To maintain backwards compatibility libvirt
      is stuck with different spelling of some of the features, but we need to
      use the full expansion to get the additional spellings. In addition to
      returning all spelling variants for all properties the full expansion
      will contain properties which are not guaranteed to be migration
      compatible. Thus, we need to combine both expansions. First we need to
      call the static expansion to limit the result to migratable properties.
      Then we can use the result of the static expansion as an input to the
      full expansion to get both canonical names and their aliases.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      bb3363c9
    • J
      qemu: Probe "max" CPU model in TCG · d7f054a5
      Jiri Denemark 提交于
      Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0
      introduces a new "max" CPU model which can be used to ask QEMU what the
      best CPU it can provide to a TCG domain is.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      d7f054a5
    • J
      qemucapstest: Update test data for QEMU 2.9.0 · 2a586b44
      Jiri Denemark 提交于
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      2a586b44
  20. 20 2月, 2017 2 次提交
  21. 07 12月, 2016 1 次提交
  22. 28 11月, 2016 1 次提交
  23. 26 11月, 2016 2 次提交
  24. 09 11月, 2016 1 次提交
  25. 12 10月, 2016 2 次提交
  26. 20 9月, 2016 1 次提交
  27. 05 8月, 2016 1 次提交