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

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

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