Messages in this thread | | | Date | Fri, 17 Jun 2022 16:49:29 +0200 | Subject | Re: [PATCH v9 2/3] s390x: KVM: guest support for topology function | From | Pierre Morel <> |
| |
On 5/16/22 16:13, Pierre Morel wrote: > > > On 5/12/22 11:24, David Hildenbrand wrote: >> On 06.05.22 11:24, Pierre Morel wrote: >>> We let the userland hypervisor know if the machine support the CPU >>> topology facility using a new KVM capability: KVM_CAP_S390_CPU_TOPOLOGY. >>> >>> The PTF instruction will report a topology change if there is any change >>> with a previous STSI_15_1_2 SYSIB. >>> Changes inside a STSI_15_1_2 SYSIB occur if CPU bits are set or clear >>> inside the CPU Topology List Entry CPU mask field, which happens with >>> changes in CPU polarization, dedication, CPU types and adding or >>> removing CPUs in a socket. >>> >>> The reporting to the guest is done using the Multiprocessor >>> Topology-Change-Report (MTCR) bit of the utility entry of the guest's >>> SCA which will be cleared during the interpretation of PTF. >>> >>> To check if the topology has been modified we use a new field of the >>> arch vCPU to save the previous real CPU ID at the end of a schedule >>> and verify on next schedule that the CPU used is in the same socket. >>> We do not report polarization, CPU Type or dedication change. >>> >>> STSI(15.1.x) gives information on the CPU configuration topology. >>> Let's accept the interception of STSI with the function code 15 and >>> let the userland part of the hypervisor handle it when userland >>> support the CPU Topology facility. >>> >>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> >> >> [...] >> >> >>> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c >>> index 0e8603acc105..d9e16b09c8bf 100644 >>> --- a/arch/s390/kvm/priv.c >>> +++ b/arch/s390/kvm/priv.c >>> @@ -874,10 +874,12 @@ static int handle_stsi(struct kvm_vcpu *vcpu) >>> if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE) >>> return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP); >>> - if (fc > 3) { >>> - kvm_s390_set_psw_cc(vcpu, 3); >>> - return 0; >>> - } >>> + if (fc > 3 && fc != 15) >>> + goto out_no_data; >>> + >>> + /* fc 15 is provided with PTF/CPU topology support */ >>> + if (fc == 15 && !test_kvm_facility(vcpu->kvm, 11)) >>> + goto out_no_data; >> >> >> Maybe shorter as >> >> if (fc == 15 && !test_kvm_facility(vcpu->kvm, 11)) >> goto out_no_data; >> else if (fc > 3) >> goto out_no_data; >> > > yes.
hum, sorry, but no.
when test_kvm_facility(11) is true then !test_kvm_facility(11) is false and the first test fails and the second succeed jumping to out_no_data for fc == 15
I can use what I proposed with a comment to make it better readable. What about:
/* Bailout forbidden function codes */ if (fc > 3 && fc != 15) goto out_no_data; /* fc 15 is provided with PTF/CPU topology support */ if (fc == 15 && !test_kvm_facility(vcpu->kvm, 11)) goto out_no_data;
> >> >> Apart from that, LGTM. >> > > Thanks, > Pierre >
-- Pierre Morel IBM Lab Boeblingen
| |