Re: [PATCH v10 3/9] s390x/cpu_topology: resetting the Topology-Change-Report

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

On 10/27/22 11:58, Cédric Le Goater wrote:
> On 10/27/22 11:11, Pierre Morel wrote:
>>
>>
>> On 10/27/22 10:14, Thomas Huth wrote:
>>> On 12/10/2022 18.21, Pierre Morel wrote:
>>>> During a subsystem reset the Topology-Change-Report is cleared
>>>> by the machine.
>>>> Let's ask KVM to clear the Modified Topology Change Report (MTCR)
>>>>   bit of the SCA in the case of a subsystem reset.
>>>>
>>>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>>>> Reviewed-by: Nico Boehr <nrb@linux.ibm.com>
>>>> Reviewed-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
>>>> ---
>>>>   target/s390x/cpu.h           |  1 +
>>>>   target/s390x/kvm/kvm_s390x.h |  1 +
>>>>   hw/s390x/cpu-topology.c      | 12 ++++++++++++
>>>>   hw/s390x/s390-virtio-ccw.c   |  1 +
>>>>   target/s390x/cpu-sysemu.c    |  7 +++++++
>>>>   target/s390x/kvm/kvm.c       | 23 +++++++++++++++++++++++
>>>>   6 files changed, 45 insertions(+)
>>>>
>>>> diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
>>>> index d604aa9c78..9b35795ac8 100644
>>>> --- a/target/s390x/cpu.h
>>>> +++ b/target/s390x/cpu.h
>>>> @@ -825,6 +825,7 @@ void s390_enable_css_support(S390CPU *cpu);
>>>>   void s390_do_cpu_set_diag318(CPUState *cs, run_on_cpu_data arg);
>>>>   int s390_assign_subch_ioeventfd(EventNotifier *notifier, uint32_t 
>>>> sch_id,
>>>>                                   int vq, bool assign);
>>>> +void s390_cpu_topology_reset(void);
>>>>   #ifndef CONFIG_USER_ONLY
>>>>   unsigned int s390_cpu_set_state(uint8_t cpu_state, S390CPU *cpu);
>>>>   #else
>>>> diff --git a/target/s390x/kvm/kvm_s390x.h 
>>>> b/target/s390x/kvm/kvm_s390x.h
>>>> index aaae8570de..a13c8fb9a3 100644
>>>> --- a/target/s390x/kvm/kvm_s390x.h
>>>> +++ b/target/s390x/kvm/kvm_s390x.h
>>>> @@ -46,5 +46,6 @@ void kvm_s390_crypto_reset(void);
>>>>   void kvm_s390_restart_interrupt(S390CPU *cpu);
>>>>   void kvm_s390_stop_interrupt(S390CPU *cpu);
>>>>   void kvm_s390_set_diag318(CPUState *cs, uint64_t diag318_info);
>>>> +int kvm_s390_topology_set_mtcr(uint64_t attr);
>>>>   #endif /* KVM_S390X_H */
>>>> diff --git a/hw/s390x/cpu-topology.c b/hw/s390x/cpu-topology.c
>>>> index c73cebfe6f..9f202621d0 100644
>>>> --- a/hw/s390x/cpu-topology.c
>>>> +++ b/hw/s390x/cpu-topology.c
>>>> @@ -107,6 +107,17 @@ static void s390_topology_realize(DeviceState 
>>>> *dev, Error **errp)
>>>>       qemu_mutex_init(&topo->topo_mutex);
>>>>   }
>>>> +/**
>>>> + * s390_topology_reset:
>>>> + * @dev: the device
>>>> + *
>>>> + * Calls the sysemu topology reset
>>>> + */
>>>> +static void s390_topology_reset(DeviceState *dev)
>>>> +{
>>>> +    s390_cpu_topology_reset();
>>>> +}
>>>> +
>>>>   /**
>>>>    * topology_class_init:
>>>>    * @oc: Object class
>>>> @@ -120,6 +131,7 @@ static void topology_class_init(ObjectClass *oc, 
>>>> void *data)
>>>>       dc->realize = s390_topology_realize;
>>>>       set_bit(DEVICE_CATEGORY_MISC, dc->categories);
>>>> +    dc->reset = s390_topology_reset;
>>>>   }
>>>>   static const TypeInfo cpu_topology_info = {
>>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>>> index aa99a62e42..362378454a 100644
>>>> --- a/hw/s390x/s390-virtio-ccw.c
>>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>>> @@ -113,6 +113,7 @@ static const char *const reset_dev_types[] = {
>>>>       "s390-flic",
>>>>       "diag288",
>>>>       TYPE_S390_PCI_HOST_BRIDGE,
>>>> +    TYPE_S390_CPU_TOPOLOGY,
>>>>   };
>>>>   static void subsystem_reset(void)
>>>> diff --git a/target/s390x/cpu-sysemu.c b/target/s390x/cpu-sysemu.c
>>>> index 948e4bd3e0..707c0b658c 100644
>>>> --- a/target/s390x/cpu-sysemu.c
>>>> +++ b/target/s390x/cpu-sysemu.c
>>>> @@ -306,3 +306,10 @@ void s390_do_cpu_set_diag318(CPUState *cs, 
>>>> run_on_cpu_data arg)
>>>>           kvm_s390_set_diag318(cs, arg.host_ulong);
>>>>       }
>>>>   }
>>>> +
>>>> +void s390_cpu_topology_reset(void)
>>>> +{
>>>> +    if (kvm_enabled()) {
>>>> +        kvm_s390_topology_set_mtcr(0);
>>>> +    }
>>>> +}
>>>> diff --git a/target/s390x/kvm/kvm.c b/target/s390x/kvm/kvm.c
>>>> index f96630440b..9c994d27d5 100644
>>>> --- a/target/s390x/kvm/kvm.c
>>>> +++ b/target/s390x/kvm/kvm.c
>>>> @@ -2585,3 +2585,26 @@ int kvm_s390_get_zpci_op(void)
>>>>   {
>>>>       return cap_zpci_op;
>>>>   }
>>>> +
>>>> +int kvm_s390_topology_set_mtcr(uint64_t attr)
>>>> +{
>>>> +    struct kvm_device_attr attribute = {
>>>> +        .group = KVM_S390_VM_CPU_TOPOLOGY,
>>>> +        .attr  = attr,
>>>> +    };
>>>> +    int ret;
>>>> +
>>>> +    if (!s390_has_feat(S390_FEAT_CONFIGURATION_TOPOLOGY)) {
>>>> +        return -EFAULT;
>>>
>>> EFAULT is something that indicates a bad address (e.g. a segmentation 
>>> fault) ... so this definitely sounds like a bad choice for an error 
>>> code here.
>>
>> Hum, yes, ENODEV seems besser no?
> 
> -ENOTSUP would be 'meilleur' may be ?  :)

yes better :)

thanks,
Pierre

-- 
Pierre Morel
IBM Lab Boeblingen