Am 13.12.22 um 14:57 schrieb Janis Schoetterl-Glausch:
On Tue, 2022-12-13 at 14:41 +0100, Christian Borntraeger wrote:
Am 12.12.22 um 11:17 schrieb Thomas Huth:
On 12/12/2022 11.10, Pierre Morel wrote:
On 12/12/22 10:07, Thomas Huth wrote:
On 12/12/2022 09.51, Pierre Morel wrote:
On 12/9/22 14:32, Thomas Huth wrote:
On 08/12/2022 10.44, Pierre Morel wrote:
Hi,
Implementation discussions
==========================
CPU models
----------
Since the S390_FEAT_CONFIGURATION_TOPOLOGY is already in the CPU model
for old QEMU we could not activate it as usual from KVM but needed
a KVM capability: KVM_CAP_S390_CPU_TOPOLOGY.
Checking and enabling this capability enables
S390_FEAT_CONFIGURATION_TOPOLOGY.
Migration
---------
Once the S390_FEAT_CONFIGURATION_TOPOLOGY is enabled in the source
host the STFL(11) is provided to the guest.
Since the feature is already in the CPU model of older QEMU,
a migration from a new QEMU enabling the topology to an old QEMU
will keep STFL(11) enabled making the guest get an exception for
illegal operation as soon as it uses the PTF instruction.
I now thought that it is not possible to enable "ctop" on older QEMUs since the don't enable the KVM capability? ... or is it still somehow possible? What did I miss?
Thomas
Enabling ctop with ctop=on on old QEMU is not possible, this is right.
But, if STFL(11) is enable in the source KVM by a new QEMU, I can see that even with -ctop=off the STFL(11) is migrated to the destination.
This does not make sense. the cpu model and stfle values are not migrated. This is re-created during startup depending on the command line parameters of -cpu.
Thats why source and host have the same command lines for -cpu. And STFLE.11 must not be set on the SOURCE of ctop is off.
What about linux? I didn't look to thoroughly at it, but it caches the stfle bits, doesn't it?
So if the migration succeeds, even tho it should not, it will look to the guest like the facility is enabled.
That is true, but the migration should not succeed in that case unless you use an unsafe way of migrating. And the cpu model was exactly added to block those unsafe way.
One thing:
-cpu host is unsafe (host-passthrough in libvirt speak). Either use host-model or a fully specified model like z14.2,ctop=on....
