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

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

On 11/17/22 10:31, Pierre Morel wrote:
> 
> 
> 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

I forgot to say that I mean in the examples above without using a flag.

Of course using a flag like -ctop=off in NEW_QEMU/new_machine allows
to migrate from and to old_machines in an old QEMU.

Also I had the same behavior already in V9 by having a VMState without 
the creation of a machine property, a new cpu feature and a new cpu flag.






> 
> Is this something we can accept?
> 
> regards,
> Pierre
> 

-- 
Pierre Morel
IBM Lab Boeblingen