Commit Graph

5 Commits

Author SHA1 Message Date
Shalini Chellathurai Saroja
9d5f9b7ae8 tests: add capabilities for QEMU 5.2.0 on s390x
Let us introduce the xml and reply files for QEMU 5.2.0 on s390x.

Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-12-17 12:10:40 +01:00
Bjoern Walk
763416e192 qemu: capabilities: update qemu-4.2 capabilities for s390x
Update s390x capabilities for QEMU 4.2 with the actual GA version for
QEMU and on the latest z15 machine.

This picks up the new blockdev capability, so we need to refresh a bunch
of test cases as well.

Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-04-08 14:46:24 +02:00
Jiri Denemark
24d8202294 qemu: Use host-model CPU on s390 by default
On s390 machines host-passthrough and host-model CPUs result in the same
guest ABI (with QEMU new enough to be able to tell us what "host" CPU is
expanded to, which was implemented around 2.9.0). So instead of using
host-passthrough CPU when there's no CPU specified in a domain XML we
can safely use host-model and benefit from CPU compatibility checks
during migration, snapshot restore and similar operations.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-25 15:29:19 +01:00
Jiri Denemark
5e939cea89 qemu: Store default CPU in domain XML
When starting a domain without a CPU model specified in the domain XML,
QEMU will choose a default one. Which is fine unless the domain gets
migrated to another host because libvirt doesn't perform any CPU ABI
checks and the virtual CPU provided by QEMU on the destination host can
differ from the one on the source host.

With QEMU 4.2.0 we can probe for the default CPU model used by QEMU for
a particular machine type and store it in the domain XML. This way the
chosen CPU model is more visible to users and libvirt will make sure
the guest will see the exact same CPU after migration.

Architecture specific notes
- aarch64: We only set the default CPU for TCG domains as KVM requires
  explicit "-cpu host" to work.

- ppc64: The default CPU for KVM is "host" thanks to some hacks in QEMU,
  we will translate the default model to the model corresponding to the
  host CPU ("POWER8" on a Power8 host, "POWER9" on Power9 host, etc.).
  This is not a problem as the corresponding CPU model is in fact an
  alias for "host". This is probably not ideal, but it's not wrong and
  the default virtual CPU configured by libvirt is the same QEMU would
  use. TCG uses various CPU models depending on machine type and its
  version.

- s390x: The default CPU for KVM is "host" while TCG defaults to "qemu".

- x86_64: The default CPU model (qemu64) is not runnable on any host
  with KVM, but QEMU just disables unavailable features and starts
  happily.

https://bugzilla.redhat.com/show_bug.cgi?id=1598151
https://bugzilla.redhat.com/show_bug.cgi?id=1598162

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-20 17:22:07 +01:00
Jiri Denemark
f5466786ec qemuxml2*test: Add test cases for default CPU models on s390x
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-20 17:22:07 +01:00