linux-kernel - Re: [PATCH v2 18/30] KVM: s390: pci: provide routines for enabling/disabling interpretation

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: <1c5009ef-8ec1-ed0a-653a-1f490a9f8458@linux.ibm.com>
Date:   Mon, 24 Jan 2022 10:14:23 -0500
From:   Matthew Rosato <mjrosato@...ux.ibm.com>
To:     Pierre Morel <pmorel@...ux.ibm.com>, linux-s390@...r.kernel.org
Cc:     alex.williamson@...hat.com, cohuck@...hat.com,
        schnelle@...ux.ibm.com, farman@...ux.ibm.com,
        borntraeger@...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 v2 18/30] KVM: s390: pci: provide routines for
 enabling/disabling interpretation

On 1/24/22 9:36 AM, Pierre Morel wrote:
> 
> 
> On 1/14/22 21:31, Matthew Rosato wrote:
>> These routines will be wired into the vfio_pci_zdev ioctl handlers to
>> respond to requests to enable / disable a device for zPCI Load/Store
>> interpretation.
>>
>> The first time such a request is received, enable the necessary 
>> facilities
>> for the guest.
>>
>> Signed-off-by: Matthew Rosato <mjrosato@...ux.ibm.com>
>> ---
>>   arch/s390/include/asm/kvm_pci.h |  4 ++
>>   arch/s390/kvm/pci.c             | 99 +++++++++++++++++++++++++++++++++
>>   arch/s390/pci/pci.c             |  3 +
>>   3 files changed, 106 insertions(+)
>>
>> diff --git a/arch/s390/include/asm/kvm_pci.h 
>> b/arch/s390/include/asm/kvm_pci.h
>> index aafee2976929..072401aa7922 100644
>> --- a/arch/s390/include/asm/kvm_pci.h
>> +++ b/arch/s390/include/asm/kvm_pci.h
>> @@ -26,4 +26,8 @@ int kvm_s390_pci_dev_open(struct zpci_dev *zdev);
>>   void kvm_s390_pci_dev_release(struct zpci_dev *zdev);
>>   void kvm_s390_pci_attach_kvm(struct zpci_dev *zdev, struct kvm *kvm);
>> +int kvm_s390_pci_interp_probe(struct zpci_dev *zdev);
>> +int kvm_s390_pci_interp_enable(struct zpci_dev *zdev);
>> +int kvm_s390_pci_interp_disable(struct zpci_dev *zdev);
>> +
>>   #endif /* ASM_KVM_PCI_H */
>> diff --git a/arch/s390/kvm/pci.c b/arch/s390/kvm/pci.c
>> index dae853da6df1..122d0992b521 100644
>> --- a/arch/s390/kvm/pci.c
>> +++ b/arch/s390/kvm/pci.c
>> @@ -12,7 +12,9 @@
>>   #include <asm/kvm_pci.h>
>>   #include <asm/pci.h>
>>   #include <asm/pci_insn.h>
>> +#include <asm/sclp.h>
>>   #include "pci.h"
>> +#include "kvm-s390.h"
>>   struct zpci_aift *aift;
>> @@ -143,6 +145,103 @@ int kvm_s390_pci_aen_init(u8 nisc)
>>       return rc;
>>   }
>> +int kvm_s390_pci_interp_probe(struct zpci_dev *zdev)
>> +{
>> +    /* Must have appropriate hardware facilities */
>> +    if (!(sclp.has_zpci_lsi && test_facility(69)))
> 
> Should'nt we also test the other facilities we need for the 
> interpretation like ARNI, AISII, ASI and GISA ?
> 
> Or are we sure they are always there when ZPCI load/store interpretation 
> is available?

I think some of these are implicit based on others but I think you're 
right that we should be testing for more than this to be safe.  I think 
additionally test for AENI, AISII, AISI -- basically we should match 
what we test for in patch 17.

> 
> 
>> +        return -EINVAL;
>> +
>> +    /* Must have a KVM association registered */
>> +    if (!zdev->kzdev || !zdev->kzdev->kvm)
>> +        return -EINVAL;
>> +
>> +    return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(kvm_s390_pci_interp_probe);
>> +
>> +int kvm_s390_pci_interp_enable(struct zpci_dev *zdev)
>> +{
>> +    u32 gd;
>> +    int rc;
>> +
>> +    if (!zdev->kzdev || !zdev->kzdev->kvm)
>> +        return -EINVAL;
>> +
>> +    /*
>> +     * If this is the first request to use an interpreted device, 
>> make the
>> +     * necessary vcpu changes
>> +     */
>> +    if (!zdev->kzdev->kvm->arch.use_zpci_interp)
>> +        kvm_s390_vcpu_pci_enable_interp(zdev->kzdev->kvm);
>> +
>> +    /*
>> +     * In the event of a system reset in userspace, the GISA designation
>> +     * may still be assigned because the device is still enabled.
>> +     * Verify it's the same guest before proceeding.
>> +     */
>> +    gd = (u32)(u64)&zdev->kzdev->kvm->arch.sie_page2->gisa;
> 
> should use the virt_to_phys transformation ?

Yes