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: <edd0dcee-12db-bc31-203a-bc1c94a072a5@linux.ibm.com>
Date:   Fri, 17 Dec 2021 10:19:01 -0500
From:   Matthew Rosato <mjrosato@...ux.ibm.com>
To:     Christian Borntraeger <borntraeger@...ux.ibm.com>,
        linux-s390@...r.kernel.org
Cc:     alex.williamson@...hat.com, cohuck@...hat.com,
        schnelle@...ux.ibm.com, farman@...ux.ibm.com, pmorel@...ux.ibm.com,
        hca@...ux.ibm.com, gor@...ux.ibm.com,
        gerald.schaefer@...ux.ibm.com, agordeev@...ux.ibm.com,
        frankja@...ux.ibm.com, david@...hat.com, imbrenda@...ux.ibm.com,
        vneethv@...ux.ibm.com, oberpar@...ux.ibm.com, freude@...ux.ibm.com,
        thuth@...hat.com, pasic@...ux.ibm.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 16/32] KVM: s390: expose the guest zPCI interpretation
 facility

On 12/17/21 10:05 AM, Christian Borntraeger wrote:
> 
> 
> Am 07.12.21 um 21:57 schrieb Matthew Rosato:
>> This facility will be used to enable interpretive execution of zPCI
>> instructions.
>>
>> Signed-off-by: Matthew Rosato <mjrosato@...ux.ibm.com>
>> ---
>>   arch/s390/kvm/kvm-s390.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index c8fe9b7c2395..09991d05c871 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -2751,6 +2751,10 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned 
>> long type)
>>           set_kvm_facility(kvm->arch.model.fac_mask, 147);
>>           set_kvm_facility(kvm->arch.model.fac_list, 147);
>>       }
>> +    if (sclp.has_zpci_interp && test_facility(69)) {
>> +        set_kvm_facility(kvm->arch.model.fac_mask, 69);
>> +        set_kvm_facility(kvm->arch.model.fac_list, 69);
>> +    }
> 
> 
> Do we need the setting of these stfle bits somewhere? I think QEMU sets 
> them as well for the guest. > We only need this when the kernel probes for this (test_kvm_facility)
> But then the question is, shouldnt
> we then simply check for sclp bits in those places?
> See also patch 19. We need to build it in a way that allows VSIE support 
> later on.
> 

Right, so this currently sets the facility bits but we don't set the 
associated guest SCLP bits.  I guess since we are not enabling for VSIE 
now it would make sense to not set either.

So then just to confirm we are on the same page:  I will drop these 
patches 16-18 and leave the kvm facilities unset until we wish to enable 
VSIE.  And then also make sure we are checking sclp bits (e.g. patch 
19).  OK?

>>       if (css_general_characteristics.aiv && test_facility(65))
>>           set_kvm_facility(kvm->arch.model.fac_mask, 65);
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ