Re: [PATCH v13 0/7] s390x: CPU Topology

[Pierre Morel <pmorel@linux.ibm.com>]

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