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

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

Gentle ping.

Did I understand the problem or am I wrong?


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