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

[Pierre Morel]

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