Re: [PATCH v9 00/10] s390x: CPU Topology

[Pierre Morel]

On 11/16/22 17:51, Christian Borntraeger wrote:
> Am 02.09.22 um 09:55 schrieb Pierre Morel:
> > Hi,
> >
> > The implementation of the CPU Topology in QEMU has been drastically
> > modified since the last patch series and the number of LOCs has been
> > greatly reduced.
> >
> > Unnecessary objects have been removed, only a single S390Topology object
> > is created to support migration and reset.
> >
> > Also a documentation has been added to the series.
> >
> >
> > To use these patches, you will need Linux V6-rc1 or newer.
> >
> > Mainline patches needed are:
> >
> > f5ecfee94493 2022-07-20 KVM: s390: resetting the Topology-Change-Report
> > 24fe0195bc19 2022-07-20 KVM: s390: guest support for topology function
> > 0130337ec45b 2022-07-20 KVM: s390: Cleanup ipte lock access and SIIF 
> > fac..
> >
> > Currently this code is for KVM only, I have no idea if it is interesting
> > to provide a TCG patch. If ever it will be done in another series.
> >
> > To have a better understanding of the S390x CPU Topology and its
> > implementation in QEMU you can have a look at the documentation in the
> > last patch.
> >
> > New in this series
> > ==================
> >
> >    s390x/cpus: Make absence of multithreading clear
> >
> > This patch makes clear that CPU-multithreading is not supported in
> > the guest.
> >
> >    s390x/cpu topology: core_id sets s390x CPU topology
> >
> > This patch uses the core_id to build the container topology
> > and the placement of the CPU inside the container.
> >
> >    s390x/cpu topology: reporting the CPU topology to the guest
> >
> > This patch is based on the fact that the CPU type for guests
> > is always IFL, CPUs are always dedicated and the polarity is
> > always horizontal.
> > This may change in the future.
> >
> >    hw/core: introducing drawer and books for s390x
> >    s390x/cpu: reporting drawers and books topology to the guest
> >
> > These two patches extend the topology handling to add two
> > new containers levels above sockets: books and drawers.
> >
> > The subject of the last patches is clear enough (I hope).
> >
> > Regards,
> > Pierre
> >
> > Pierre Morel (10):
> >    s390x/cpus: Make absence of multithreading clear
> >    s390x/cpu topology: core_id sets s390x CPU topology
> >    s390x/cpu topology: reporting the CPU topology to the guest
> >    hw/core: introducing drawer and books for s390x
> >    s390x/cpu: reporting drawers and books topology to the guest
> >    s390x/cpu_topology: resetting the Topology-Change-Report
> >    s390x/cpu_topology: CPU topology migration
> >    target/s390x: interception of PTF instruction
> >    s390x/cpu_topology: activating CPU topology
>
>
> Do we really need a machine property? As far as I can see, old QEMU
> cannot  activate the ctop facility with old and new kernel unless it
> enables CAP_S390_CPU_TOPOLOGY. I do get
> oldqemu .... -cpu z14,ctop=on
> qemu-system-s390x: Some features requested in the CPU model are not 
> available in the configuration: ctop
>
> With the newer QEMU we can. So maybe we can simply have a topology (and
> then a cpu model feature) in new QEMUs and non in old. the cpu model
> would then also fence migration from enabled to disabled.

OK, I can check this.
In this case migration with topology will be if I understand correctly:

NEW_QEMU/old_machine <-> NEW_QEMU/old_machine OK
While
OLD_QEMU/old_machine <-> NEW_QEMU/old_machine KO
NEW_QEMU/old_machine <-> OLD_QEMU/old_machine KO

Is this something we can accept?

regards,
Pierre

--
Pierre Morel
IBM Lab Boeblingen