qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Pierre Morel <pmorel@linux.ibm.com>
To: Thomas Huth <thuth@redhat.com>, qemu-s390x@nongnu.org
Cc: david@redhat.com, cohuck@redhat.com,
	richard.henderson@linaro.org, qemu-devel@nongnu.org,
	pasic@linux.ibm.com, borntraeger@de.ibm.com
Subject: Re: [PATCH v2 3/5] s390x: topology: CPU topology objects and structures
Date: Tue, 7 Sep 2021 14:45:18 +0200	[thread overview]
Message-ID: <c9193765-adae-d179-8a14-8bc88a288fe0@linux.ibm.com> (raw)
In-Reply-To: <aceb16ce-b944-b00b-0624-5b5dd41accf0@redhat.com>



On 9/7/21 9:32 AM, Thomas Huth wrote:
> On 22/07/2021 19.42, Pierre Morel wrote:
>> We use new objects to have a dynamic administration of the CPU topology.
>> The highier level object is the S390 book. In a first implementation
> 

> 
> I didn't spot any migration related code in here ... is this already 
> migration-safe?
> 

Not sure at all.

The topology may change at any moment and we interpret PTF, the 
instruction which tell us if the topology changed.
Obviously the topology on the target may not be the same as on the source.

So what I propose is to disable topology change during the migration:
- on migration start, disable PTF interpretation and block the 
topology_change _report in the emulation.
- on migration end set back PTF interpretation and unblock the emulation

In the case, in discussion with David on KVM, that we do not emulate PTF 
for hosts without the stfl(11) we can even make it simpler in QEMU by 
always reporting "no change" for PTF 2 in the emulation.

Note that the Linux kernel, even if the topology can change at any 
moment use a polling every minute to check the topology changes, so I 
guess we can ignore the optimization during the migration.

What do you think?


-- 
Pierre Morel
IBM Lab Boeblingen


  parent reply	other threads:[~2021-09-07 13:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-22 17:42 [PATCH v2 0/5] s390x: CPU Topology Pierre Morel
2021-07-22 17:42 ` [PATCH v2 1/5] s390x: kvm: topology: Linux header update Pierre Morel
2021-07-22 17:42 ` [PATCH v2 2/5] s390x: kvm: topology: interception of PTF instruction Pierre Morel
2021-08-03  8:10   ` Pierre Morel
2021-09-06 17:21   ` Thomas Huth
2021-09-07  8:40     ` Pierre Morel
2021-07-22 17:42 ` [PATCH v2 3/5] s390x: topology: CPU topology objects and structures Pierre Morel
2021-09-07  7:32   ` Thomas Huth
2021-09-07  9:18     ` Pierre Morel
2021-09-07 12:45     ` Pierre Morel [this message]
2021-09-29  8:12       ` Thomas Huth
2021-09-30  8:26         ` Pierre Morel
2021-07-22 17:42 ` [PATCH v2 4/5] s390x: topology: Topology list entries and SYSIB 15.x.x Pierre Morel
2021-09-07  7:46   ` Thomas Huth
2021-09-07  9:39     ` Pierre Morel
2021-09-07  7:54   ` Thomas Huth
2021-09-07  9:49     ` Pierre Morel
2021-07-22 17:42 ` [PATCH v2 5/5] s390x: topology: implementating Store Topology System Information Pierre Morel
2021-09-07  8:00   ` Thomas Huth
2021-09-07  9:52     ` Pierre Morel
2021-08-26  9:22 ` [PATCH v2 0/5] s390x: CPU Topology Pierre Morel
2021-08-30  9:54   ` Christian Borntraeger
2021-08-30 11:59     ` 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=c9193765-adae-d179-8a14-8bc88a288fe0@linux.ibm.com \
    --to=pmorel@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --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).