qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
To: Pierre Morel <pmorel@linux.ibm.com>, qemu-s390x@nongnu.org
Cc: qemu-devel@nongnu.org, borntraeger@de.ibm.com,
	pasic@linux.ibm.com, richard.henderson@linaro.org,
	david@redhat.com, thuth@redhat.com, cohuck@redhat.com,
	mst@redhat.com, pbonzini@redhat.com, kvm@vger.kernel.org,
	ehabkost@redhat.com, marcel.apfelbaum@gmail.com,
	eblake@redhat.com, armbru@redhat.com, seiden@linux.ibm.com,
	nrb@linux.ibm.com, frankja@linux.ibm.com
Subject: Re: [PATCH v9 07/10] s390x/cpu_topology: CPU topology migration
Date: Thu, 08 Sep 2022 20:04:37 +0200	[thread overview]
Message-ID: <5f127a8be58d0842c6d94d682538af55f4eef64f.camel@linux.ibm.com> (raw)
In-Reply-To: <20220902075531.188916-8-pmorel@linux.ibm.com>

On Fri, 2022-09-02 at 09:55 +0200, Pierre Morel wrote:
> The migration can only take place if both source and destination
> of the migration both use or both do not use the CPU topology
> facility.
> 
> We indicate a change in topology during migration postload for the
> case the topology changed between source and destination.

You always set the report bit after migration, right?
In the last series you actually migrated the bit.
Why the change? With the code you have actually migrating the bit isn't
hard.
> 
> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> ---
>  hw/s390x/cpu-topology.c         | 79 +++++++++++++++++++++++++++++++++
>  include/hw/s390x/cpu-topology.h |  1 +
>  target/s390x/cpu-sysemu.c       |  8 ++++
>  target/s390x/cpu.h              |  1 +
>  4 files changed, 89 insertions(+)
> 
> diff --git a/hw/s390x/cpu-topology.c b/hw/s390x/cpu-topology.c
> index 6098d6ea1f..b6bf839e40 100644
> --- a/hw/s390x/cpu-topology.c
> +++ b/hw/s390x/cpu-topology.c
> @@ -19,6 +19,7 @@
>  #include "target/s390x/cpu.h"
>  #include "hw/s390x/s390-virtio-ccw.h"
>  #include "hw/s390x/cpu-topology.h"
> +#include "migration/vmstate.h"
>  
>  S390Topology *s390_get_topology(void)
>  {
> @@ -132,6 +133,83 @@ static void s390_topology_reset(DeviceState *dev)
>      s390_cpu_topology_reset();
>  }
>  
> +/**
> + * cpu_topology_postload
> + * @opaque: a pointer to the S390Topology
> + * @version_id: version identifier
> + *
> + * We check that the topology is used or is not used
> + * on both side identically.
> + *
> + * If the topology is in use we set the Modified Topology Change Report
> + * on the destination host.
> + */
> +static int cpu_topology_postload(void *opaque, int version_id)
> +{
> +    S390Topology *topo = opaque;
> +    int ret;
> +
> +    if (topo->topology_needed != s390_has_feat(S390_FEAT_CONFIGURATION_TOPOLOGY)) {

Does this function even run if topology_needed is false?
In that case there is no data saved, so no reason to load it either.
If so you can only check that both the source and the destination have
the feature enabled. You would need to always send the topology VMSD in
order to check that the feature is disabled.

Does qemu allow you to attempt to migrate to a host with another cpu
model?
If it disallowes that you wouldn't need to do any checks, right?

> +        if (topo->topology_needed) {
> +            error_report("Topology facility is needed in destination");
> +        } else {
> +            error_report("Topology facility can not be used in destination");
> +        }
> +        return -EINVAL;
> +    }
> +
> +    /* We do not support CPU Topology, all is good */
> +    if (!s390_has_feat(S390_FEAT_CONFIGURATION_TOPOLOGY)) {
> +        return 0;
> +    }
> +
> +    /* We support CPU Topology, set the MTCR */
> +    ret = s390_cpu_topology_mtcr_set();
> +    if (ret) {
> +        error_report("Failed to set MTCR: %s", strerror(-ret));
> +    }
> +    return ret;
> +}
> +
> +/**
> + * cpu_topology_presave:
> + * @opaque: The pointer to the S390Topology
> + *
> + * Save the usage of the CPU Topology in the VM State.
> + */
> +static int cpu_topology_presave(void *opaque)
> +{
> +    S390Topology *topo = opaque;
> +
> +    topo->topology_needed = s390_has_feat(S390_FEAT_CONFIGURATION_TOPOLOGY);
> +    return 0;
> +}
> +
> +/**
> + * cpu_topology_needed:
> + * @opaque: The pointer to the S390Topology
> + *
> + * If we use the CPU Topology on the source it will be needed on the destination.
> + */
> +static bool cpu_topology_needed(void *opaque)
> +{
> +    return s390_has_feat(S390_FEAT_CONFIGURATION_TOPOLOGY);
> +}
> +
> +
> +const VMStateDescription vmstate_cpu_topology = {
> +    .name = "cpu_topology",
> +    .version_id = 1,
> +    .post_load = cpu_topology_postload,
> +    .pre_save = cpu_topology_presave,
> +    .minimum_version_id = 1,
> +    .needed = cpu_topology_needed,
> +    .fields = (VMStateField[]) {
> +        VMSTATE_BOOL(topology_needed, S390Topology),
> +        VMSTATE_END_OF_LIST()
> +    }
> +};
> +
[...]


  reply	other threads:[~2022-09-08 18:06 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-02  7:55 [PATCH v9 00/10] s390x: CPU Topology Pierre Morel
2022-09-02  7:55 ` [PATCH v9 01/10] s390x/cpus: Make absence of multithreading clear Pierre Morel
2022-09-05 11:32   ` Nico Boehr
2022-09-05 15:10     ` Pierre Morel
2022-09-05 15:23       ` Janis Schoetterl-Glausch
2022-09-05 15:42         ` Pierre Morel
2022-09-27  9:44       ` Cédric Le Goater
2022-09-28 13:21         ` Pierre Morel
2022-09-28 16:16           ` Pierre Morel
2022-09-28 16:28             ` Cédric Le Goater
2022-10-11  7:21               ` Pierre Morel
2022-10-11  7:28                 ` Cédric Le Goater
2022-09-28 18:11   ` Daniel P. Berrangé
2022-10-10 17:20     ` Pierre Morel
2022-09-02  7:55 ` [PATCH v9 02/10] s390x/cpu topology: core_id sets s390x CPU topology Pierre Morel
2022-09-05 18:11   ` Janis Schoetterl-Glausch
2022-09-12 15:34     ` Pierre Morel
2022-09-06  5:58   ` Nico Boehr
2022-09-12 15:40     ` Pierre Morel
2022-09-27 12:03   ` Cédric Le Goater
2022-09-28 13:15     ` Pierre Morel
2022-09-02  7:55 ` [PATCH v9 03/10] s390x/cpu topology: reporting the CPU topology to the guest Pierre Morel
2022-09-06  8:17   ` Nico Boehr
2022-09-28 10:03     ` Pierre Morel
2022-09-06 11:49   ` Janis Schoetterl-Glausch
2022-09-28 10:01     ` Pierre Morel
2022-09-07 10:26   ` Janis Schoetterl-Glausch
2022-09-28  9:07     ` Pierre Morel
2022-09-02  7:55 ` [PATCH v9 04/10] hw/core: introducing drawer and books for s390x Pierre Morel
2022-09-06  8:59   ` Markus Armbruster
2022-09-28  9:04     ` Pierre Morel
2022-09-28  9:06     ` Pierre Morel
2022-09-02  7:55 ` [PATCH v9 05/10] s390x/cpu: reporting drawers and books topology to the guest Pierre Morel
2022-09-07 10:36   ` Janis Schoetterl-Glausch
2022-09-28  8:55     ` Pierre Morel
2022-09-02  7:55 ` [PATCH v9 06/10] s390x/cpu_topology: resetting the Topology-Change-Report Pierre Morel
2022-09-06  8:27   ` Nico Boehr
2022-09-28  8:35     ` Pierre Morel
2022-09-08  7:57   ` Janis Schoetterl-Glausch
2022-09-28  8:46     ` Pierre Morel
2022-09-02  7:55 ` [PATCH v9 07/10] s390x/cpu_topology: CPU topology migration Pierre Morel
2022-09-08 18:04   ` Janis Schoetterl-Glausch [this message]
2022-09-28  8:34     ` Pierre Morel
2022-09-29 17:30       ` Pierre Morel
2022-09-02  7:55 ` [PATCH v9 08/10] target/s390x: interception of PTF instruction Pierre Morel
2022-09-09 16:50   ` Janis Schoetterl-Glausch
2022-09-28 13:34     ` Pierre Morel
2022-09-02  7:55 ` [PATCH v9 09/10] s390x/cpu_topology: activating CPU topology Pierre Morel
2022-09-05 15:29   ` Pierre Morel
2022-09-27 14:41   ` Cédric Le Goater
2022-09-28  8:15     ` Pierre Morel
2022-09-02  7:55 ` [PATCH v9 10/10] docs/s390x: document s390x cpu topology Pierre Morel
2022-09-12 13:41   ` Janis Schoetterl-Glausch
2022-09-28  8:19     ` Pierre Morel
2022-09-12 13:48   ` Janis Schoetterl-Glausch
2022-09-12 14:38 ` [PATCH v9 00/10] s390x: CPU Topology Janis Schoetterl-Glausch
2022-09-28  8:28   ` Pierre Morel
2022-11-16 16:51 ` Christian Borntraeger
2022-11-17  9:31   ` Pierre Morel
2022-11-17 16:38     ` Pierre Morel
2022-11-24  9:25       ` Pierre Morel
2022-11-27 10:50         ` Pierre Morel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5f127a8be58d0842c6d94d682538af55f4eef64f.camel@linux.ibm.com \
    --to=scgl@linux.ibm.com \
    --cc=armbru@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=nrb@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=pmorel@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=seiden@linux.ibm.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).