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.
It is highly possible that I missed something in the cpu model.
A solution proposed by Cedric was to add a new machine but we did not
want this because we decided that we do not want to wait for a new machine.
Another solution could be to have a we can have a new CPU feature
overruling ctop like S390_FEAT_CPU_TOPOLOGY in the last series version 12.
I am not sure it must be linked with the creation of a new machine.
The solution here in this series is to add a VMState which will block
the migration with older QEMU if the topology is activated with ctop on
a new QEMU.
Regards,
Pierre
A VMState keeping track of the S390_FEAT_CONFIGURATION_TOPOLOGY
allows to forbid the migration in such a case.
Note that the VMState will be used to hold information on the
topology once we implement topology change for a running guest.
--
Pierre Morel
IBM Lab Boeblingen
