Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <11ab9dfa-494b-5103-5f26-aa6c29567f52@linux.ibm.com>
Date:   Wed, 2 Mar 2022 18:43:03 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Subject: Re: [PATCH v18 07/18] s390/vfio-ap: refresh guest's APCB by filtering
 APQNs assigned to mdev
Content-Language: en-US
To:     jjherne@linux.ibm.com, linux-s390@vger.kernel.org,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc:     freude@linux.ibm.com, borntraeger@de.ibm.com, cohuck@redhat.com,
        mjrosato@linux.ibm.com, pasic@linux.ibm.com,
        alex.williamson@redhat.com, kwankhede@nvidia.com,
        fiuczy@linux.ibm.com
References: <20220215005040.52697-1-akrowiak@linux.ibm.com>
 <20220215005040.52697-8-akrowiak@linux.ibm.com>
 <2b1f788b-5197-f5e8-52cf-58995d758ef7@linux.ibm.com>
From:   Tony Krowiak <akrowiak@linux.ibm.com>
In-Reply-To: <2b1f788b-5197-f5e8-52cf-58995d758ef7@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 3/2/22 14:35, Jason J. Herne wrote:
> On 2/14/22 19:50, Tony Krowiak wrote:
>> Refresh the guest's APCB by filtering the APQNs assigned to the 
>> matrix mdev
>> that do not reference an AP queue device bound to the vfio_ap device
>> driver. The mdev's APQNs will be filtered according to the following 
>> rules:
>>
>> * The APID of each adapter and the APQI of each domain that is not in 
>> the
>> host's AP configuration is filtered out.
>>
>> * The APID of each adapter comprising an APQN that does not reference a
>> queue device bound to the vfio_ap device driver is filtered. The APQNs
>> are derived from the Cartesian product of the APID of each adapter and
>> APQI of each domain assigned to the mdev.
>>
>> The control domains that are not assigned to the host's AP configuration
>> will also be filtered before assigning them to the guest's APCB.
>>
>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
>> ---
>>   drivers/s390/crypto/vfio_ap_ops.c | 96 ++++++++++++++++++++++++++++++-
>>   1 file changed, 93 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
>> b/drivers/s390/crypto/vfio_ap_ops.c
>> index 4b676a55f203..b67b2f0faeea 100644
>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>> @@ -317,6 +317,63 @@ static void vfio_ap_matrix_init(struct 
>> ap_config_info *info,
>>       matrix->adm_max = info->apxa ? info->Nd : 15;
>>   }
>>   +static void vfio_ap_mdev_filter_cdoms(struct ap_matrix_mdev 
>> *matrix_mdev)
>> +{
>> +    bitmap_and(matrix_mdev->shadow_apcb.adm, matrix_mdev->matrix.adm,
>> +           (unsigned long *)matrix_dev->info.adm, AP_DOMAINS);
>> +}
>> +
>> +/*
>> + * vfio_ap_mdev_filter_matrix - copy the mdev's AP configuration to 
>> the KVM
>> + *                guest's APCB then filter the APIDs that do not
>> + *                comprise at least one APQN that references a
>> + *                queue device bound to the vfio_ap device driver.
>> + *
>> + * @matrix_mdev: the mdev whose AP configuration is to be filtered.
>> + */
>> +static void vfio_ap_mdev_filter_matrix(unsigned long *apm, unsigned 
>> long *aqm,
>> +                       struct ap_matrix_mdev *matrix_mdev)
>> +{
>> +    int ret;
>> +    unsigned long apid, apqi, apqn;
>> +
>> +    ret = ap_qci(&matrix_dev->info);
>> +    if (ret)
>> +        return;
>> +
>> +    vfio_ap_matrix_init(&matrix_dev->info, &matrix_mdev->shadow_apcb);
>
> Do you need to call vfio_ap_matrix_init here? It seems to me like this 
> would
> only be necesarry if apxa could be dynamically added or removed. Here 
> is a
> copy of vfio_ap_matrix_init, for reference:
>
> static void vfio_ap_matrix_init(struct ap_config_info *info,
>                 struct ap_matrix *matrix)
> {
>     matrix->apm_max = info->apxa ? info->Na : 63;
>     matrix->aqm_max = info->apxa ? info->Nd : 15;
>     matrix->adm_max = info->apxa ? info->Nd : 15;
> }
>
> It seems like this should be figured out once and stored when the
> ap_matrix_mdev struct is first created. Unless I'm wrong, and the 
> status of
> apxa can change dynamically, in which case the maximums would need to be
> updated somewhere.

It's an interesting question to which I don't have a definitive answer. 
I'll run it
by our architects. On the other hand, making this call here is not entirely
unreasonable and merely superfluous at worst, but I'll look into it.

Tony K

>
>