Re: [PATCH v9 2/3] s390x: KVM: guest support for topology function

[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@xxxxxxxxxxxxx>
> >
> > [...]
> >
> >
> > > 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