lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cb9f48e6-172b-4498-4595-940c26e36f48@linux.ibm.com>
Date:   Mon, 4 Jul 2022 15:54:10 +0200
From:   Pierre Morel <pmorel@...ux.ibm.com>
To:     Janis Schoetterl-Glausch <scgl@...ux.ibm.com>, kvm@...r.kernel.org
Cc:     linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        borntraeger@...ibm.com, frankja@...ux.ibm.com, cohuck@...hat.com,
        david@...hat.com, thuth@...hat.com, imbrenda@...ux.ibm.com,
        hca@...ux.ibm.com, gor@...ux.ibm.com, wintera@...ux.ibm.com,
        seiden@...ux.ibm.com, nrb@...ux.ibm.com
Subject: Re: [PATCH v11 2/3] KVM: s390: guest support for topology function



On 7/4/22 13:02, Pierre Morel wrote:
> 
> 
> On 7/4/22 11:08, Janis Schoetterl-Glausch wrote:
>> On 7/1/22 18:25, Pierre Morel wrote:

...

>>> +    if (test_kvm_facility(vcpu->kvm, 11))
>>> +        vcpu->arch.sie_block->ecb |= ECB_PTF;
>>>       if (test_kvm_facility(vcpu->kvm, 73))
>>>           vcpu->arch.sie_block->ecb |= ECB_TE;
>>>       if (!kvm_is_ucontrol(vcpu->kvm))
>>> @@ -3403,6 +3437,8 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
>>>       rc = kvm_s390_vcpu_setup(vcpu);
>>>       if (rc)
>>>           goto out_ucontrol_uninit;
>>> +
>>> +    kvm_s390_update_topology_change_report(vcpu->kvm, 1);
>>>       return 0;
>>>   out_ucontrol_uninit:
>>> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
>>> index 12c464c7cddf..046afee1be94 100644
>>> --- a/arch/s390/kvm/priv.c
>>> +++ b/arch/s390/kvm/priv.c
>>> @@ -873,10 +873,13 @@ 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;
>>> -    }
>>> +    /* Bailout forbidden function codes */
>>> +    if (fc > 3 && (fc != 15 || kvm_s390_pv_cpu_is_protected(vcpu)))
>>> +        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;
>>>       if (vcpu->run->s.regs.gprs[0] & 0x0fffff00
>>>           || vcpu->run->s.regs.gprs[1] & 0xffff0000)
>>> @@ -910,6 +913,11 @@ static int handle_stsi(struct kvm_vcpu *vcpu)
>>>               goto out_no_data;
>>>           handle_stsi_3_2_2(vcpu, (void *) mem);
>>>           break;
>>> +    case 15: /* fc 15 is fully handled in userspace */
>>> +        if (vcpu->kvm->arch.user_stsi)
>>> +            insert_stsi_usr_data(vcpu, operand2, ar, fc, sel1, sel2);
>>> +        trace_kvm_s390_handle_stsi(vcpu, fc, sel1, sel2, operand2);
>>> +        return -EREMOTE;
>>
>> This doesn't look right to me, you still return -EREMOTE if user_stsi 
>> is false.
>> The way I read the PoP here is that it is ok to set condition code 3 
>> for the else case
> 
> Yes it is what I wanted to do.
> I do not understand what I did here is stupid.

I thought again on this as I explain in another thread, I do not think 
we need to check on user_stsi here.


> 
> 

-- 
Pierre Morel
IBM Lab Boeblingen

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ