[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 3/5] s390x: topology: CPU topology objects and structures
From: |
Pierre Morel |
Subject: |
Re: [PATCH v2 3/5] s390x: topology: CPU topology objects and structures |
Date: |
Tue, 7 Sep 2021 14:45:18 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 |
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