On 13/12/2022 18.24, Pierre Morel wrote:
On 12/13/22 14:41, 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.
OK, so it is a feature
Is this with the "host" CPU model or another one? And did you
explicitly specify "ctop=off" at the command line, or are you just
using the default setting by not specifying it?
With explicit cpumodel and using ctop=off like in
sudo /usr/local/bin/qemu-system-s390x_master \
-m 512M \
-enable-kvm -smp 4,sockets=4,cores=2,maxcpus=8 \
-cpu z14,ctop=off \
-machine s390-ccw-virtio-7.2,accel=kvm \
...
Ok ... that sounds like a bug somewhere in your patches or in the kernel
code ... the guest should never see STFL bit 11 if ctop=off, should it?
Correct. If ctop=off then QEMU should disable STFLE.11 for the CPU model.
Sorry but not completely correct in the case of migration.
After a migration if the source host specifies ctop=on and target host
specifies ctop=off it does see the STFL bit 11.
The admin should not, but can, specify ctop=off on target if the source set
ctop=on. Then the target will start and run in a degraded mode.
Admin should specify the same flags on both ends, as you said above the STFL
bits are not migrated and target QEMU can not verify what the original flags
were.
However, isn't it a bug?
Is there a reason to not prevent QEMU to start with a wrong cpu model like
specifying different flags on both ends or even different cpu?
It's clearly an user error if the two QEMUs are started with different flags
on the source and destination ends. But it would be great if there was a
generic way to check for this error condition and bail out early instead of
doing the migration and let the user run into weird problems later... Does
anybody have an idea whether there is a good and easy way to implement such
a check?
Thomas
