linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Krowiak <akrowiak@linux.ibm.com>
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
Subject: Re: [PATCH v18 12/18] s390/vfio-ap: reset queues after adapter/domain unassignment
Date: Fri, 18 Mar 2022 13:54:27 -0400	[thread overview]
Message-ID: <e869ab58-432e-e451-9021-71ee65488fb0@linux.ibm.com> (raw)
In-Reply-To: <6083d83b-6867-2525-fdd8-baccde1a599f@linux.ibm.com>



On 3/15/22 10:13, Jason J. Herne wrote:
> On 2/14/22 19:50, Tony Krowiak wrote:
>> When an adapter or domain is unassigned from an mdev providing the AP
>> configuration to a running KVM guest, one or more of the guest's 
>> queues may
>> get dynamically removed. Since the removed queues could get 
>> re-assigned to
>> another mdev, they need to be reset. So, when an adapter or domain is
>> unassigned from the mdev, the queues that are removed from the guest's
>> AP configuration will be reset.
>>
>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
>> ---
> ...
>>   +static void vfio_ap_unlink_apqn_fr_mdev(struct ap_matrix_mdev 
>> *matrix_mdev,
>> +                    unsigned long apid, unsigned long apqi,
>> +                    struct ap_queue_table *qtable)
>> +{
>> +    struct vfio_ap_queue *q;
>> +
>> +    q = vfio_ap_mdev_get_queue(matrix_mdev, AP_MKQID(apid, apqi));
>> +    /* If the queue is assigned to the matrix mdev, unlink it. */
>> +    if (q)
>> +        vfio_ap_unlink_queue_fr_mdev(q);
>> +
>> +    /* If the queue is assigned to the APCB, store it in @qtable. */
>> +    if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) &&
>> +        test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm))
>> +        hash_add(qtable->queues, &q->mdev_qnode, q->apqn);
>> +}
>> +
>> +/**
>> + * vfio_ap_mdev_unlink_adapter - unlink all queues associated with 
>> unassigned
>> + *                 adapter from the matrix mdev to which the
>> + *                 adapter was assigned.
>> + * @matrix_mdev: the matrix mediated device to which the adapter was 
>> assigned.
>> + * @apid: the APID of the unassigned adapter.
>> + * @qtable: table for storing queues associated with unassigned 
>> adapter.
>> + */
>>   static void vfio_ap_mdev_unlink_adapter(struct ap_matrix_mdev 
>> *matrix_mdev,
>> -                    unsigned long apid)
>> +                    unsigned long apid,
>> +                    struct ap_queue_table *qtable)
>>   {
>>       unsigned long apqi;
>> +
>> +    for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm, AP_DOMAINS)
>> +        vfio_ap_unlink_apqn_fr_mdev(matrix_mdev, apid, apqi, qtable);
>> +}
>
> Here is an alternate version of the above two functions that stops the
> profileration of the qtables variable into vfio_ap_unlink_apqn_fr_mdev.
> It may seem like a change with no benefit, but it simplifies things a
> bit and avoids the reader from having to sink three functions deep to
> find out where qtables is used. This is 100% untested.
>
>
> static bool vfio_ap_unlink_apqn_fr_mdev(struct ap_matrix_mdev 
> *matrix_mdev,
>                     unsigned long apid, unsigned long apqi)
> {
>     struct vfio_ap_queue *q;
>
>     q = vfio_ap_mdev_get_queue(matrix_mdev, AP_MKQID(apid, apqi));
>     /* If the queue is assigned to the matrix mdev, unlink it. */
>     if (q) {
>         vfio_ap_unlink_queue_fr_mdev(q);
>         return true;
>     }
>     return false;
> }
>
> static void vfio_ap_mdev_unlink_adapter(struct ap_matrix_mdev 
> *matrix_mdev,
>                     unsigned long apid,
>                     struct ap_queue_table *qtable)
> {
>     unsigned long apqi;
>     bool unlinked;
>
>     for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm, AP_DOMAINS) {
>         unlinked = vfio_ap_unlink_apqn_fr_mdev(matrix_mdev, apid, 
> apqi, qtable);
>
>         if (unlinked && qtable) {
>             if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) &&
>                 test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm))
>                 hash_add(qtable->queues, &q->mdev_qnode,
>                      q->apqn);
>         }
>     }
> }

This code didn't compile because in the function immediately above,
the variable q is not defined nor is it initialized with a value. What I did
to fix that is return  the vfio_ap_queue pointer from the
vfio_ap_unlink_apqn_fr_mdev function and checked the return value
for NULL instead of the boolean:

vfio_ap_queue *q;
...
q = vfio_ap_unlink_apqn_fr_mdev(matrix_mdev, apid, apqi, qtable);
...
if (q && qtable)
...

>
>
>> +static void vfio_ap_mdev_hot_unplug_adapter(struct ap_matrix_mdev 
>> *matrix_mdev,
>> +                        unsigned long apid)
>> +{
>> +    int bkt;
>>       struct vfio_ap_queue *q;
>> +    struct ap_queue_table qtable;
>> +    hash_init(qtable.queues);
>> +    vfio_ap_mdev_unlink_adapter(matrix_mdev, apid, &qtable);
>> +
>> +    if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm)) {
>> +        clear_bit_inv(apid, matrix_mdev->shadow_apcb.apm);
>> +        vfio_ap_mdev_hotplug_apcb(matrix_mdev);
>> +    }
>>   -    for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm, AP_DOMAINS) {
>> -        q = vfio_ap_mdev_get_queue(matrix_mdev, AP_MKQID(apid, apqi));
>> +    vfio_ap_mdev_reset_queues(&qtable);
>>   -        if (q)
>> -            vfio_ap_mdev_unlink_queue(q);
>> +    hash_for_each(qtable.queues, bkt, q, mdev_qnode) {
>
> This comment applies to all instances of btk: What is btk? Can we come
> up with a more descriptive name?

If you look at the hash_for_each macro, you will see that I used the exact
same variable name as the macro does to indicate it is a bucket loop
cursor. Since that is a long name I'll go with loop_cursor.

>
>
>> +        vfio_ap_unlink_mdev_fr_queue(q);
>> +        hash_del(&q->mdev_qnode);
>>       }
>>   }
> ...
>> @@ -1273,9 +1320,9 @@ static void vfio_ap_mdev_unset_kvm(struct 
>> ap_matrix_mdev *matrix_mdev,
>>           mutex_lock(&kvm->lock);
>>           mutex_lock(&matrix_dev->mdevs_lock);
>>   -        kvm_arch_crypto_clear_masks(kvm);
>> -        vfio_ap_mdev_reset_queues(matrix_mdev);
>> -        kvm_put_kvm(kvm);
>> +        kvm_arch_crypto_clear_masks(matrix_mdev->kvm);
>> +        vfio_ap_mdev_reset_queues(&matrix_mdev->qtable);
>> +        kvm_put_kvm(matrix_mdev->kvm);
>>           matrix_mdev->kvm = NULL;
>
> I understand changing the call to vfio_ap_mdev_reset_queues, but why 
> are we changing the
> kvm pointer on the surrounding lines?

In reality, both pointers are one in the same given the two callers pass
matrix_mdev->kvm into the function. I'm not sure why that is the case,
it is probably a remnant from the commits that fixed the lockdep splat;
however, there is no reason other than I've gotten used to retrieving the
KVM pointer from the ap_matrix_mdev structure. In reality, there is no
reason to pass a 'struct kvm *kvm' into this function, so I'm going to
look into that and adjust accordingly.

>
>
>> mutex_unlock(&matrix_dev->mdevs_lock);
>> @@ -1328,14 +1375,17 @@ static int vfio_ap_mdev_reset_queue(struct 
>> vfio_ap_queue *q, unsigned int retry)
>>         if (!q)
>>           return 0;
>> +    q->reset_rc = 0;
>
> This line seems unnecessary. You set q->reset_rc in every single case 
> below, so this 0
> will always get overwritten.

Right you are. It is also unnecessary to set q->reset_rc every case when
it can be set once right after the call to ap_zapq.

>
>
>>   retry_zapq:
>>       status = ap_zapq(q->apqn);
>>       switch (status.response_code) {
>>       case AP_RESPONSE_NORMAL:
>>           ret = 0;
>> +        q->reset_rc = status.response_code;
>>           break;
>>       case AP_RESPONSE_RESET_IN_PROGRESS:
>> +        q->reset_rc = status.response_code;
>>           if (retry--) {
>>               msleep(20);
>>               goto retry_zapq;
>> @@ -1345,13 +1395,20 @@ static int vfio_ap_mdev_reset_queue(struct 
>> vfio_ap_queue *q, unsigned int retry)
>>       case AP_RESPONSE_Q_NOT_AVAIL:
>>       case AP_RESPONSE_DECONFIGURED:
>>       case AP_RESPONSE_CHECKSTOPPED:
>> -        WARN_ON_ONCE(status.irq_enabled);
>> +        WARN_ONCE(status.irq_enabled,
>> +              "PQAP/ZAPQ for %02x.%04x failed with rc=%u while IRQ 
>> enabled",
>> +              AP_QID_CARD(q->apqn), AP_QID_QUEUE(q->apqn),
>> +              status.response_code);
>> +        q->reset_rc = status.response_code;
>>           ret = -EBUSY;
>>           goto free_resources;
>>       default:
>>           /* things are really broken, give up */
>> -        WARN(true, "PQAP/ZAPQ completed with invalid rc (%x)\n",
>> +        WARN(true,
>> +             "PQAP/ZAPQ for %02x.%04x failed with invalid rc=%u\n",
>> +             AP_QID_CARD(q->apqn), AP_QID_QUEUE(q->apqn),
>>                status.response_code);
>> +        q->reset_rc = status.response_code;
>>           return -EIO;
>>       }
> ...
>


  reply	other threads:[~2022-03-18 17:54 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15  0:50 [PATCH v18 00/17] s390/vfio-ap: dynamic configuration support Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 01/18] s390/ap: driver callback to indicate resource in use Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 02/18] s390/ap: notify drivers on config changed and scan complete callbacks Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 03/18] s390/vfio-ap: use new AP bus interface to search for queue devices Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 04/18] s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 05/18] s390/vfio-ap: manage link between queue struct and matrix mdev Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 06/18] s390/vfio-ap: introduce shadow APCB Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 07/18] s390/vfio-ap: refresh guest's APCB by filtering APQNs assigned to mdev Tony Krowiak
2022-03-02 19:35   ` Jason J. Herne
2022-03-02 23:43     ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 08/18] s390/vfio-ap: allow assignment of unavailable AP queues to mdev device Tony Krowiak
2022-03-03 15:39   ` Jason J. Herne
2022-03-07 12:31     ` Tony Krowiak
2022-03-07 13:27       ` Halil Pasic
2022-03-07 14:10         ` Tony Krowiak
2022-03-07 17:10           ` Halil Pasic
2022-03-07 23:45             ` Tony Krowiak
2022-03-08 10:06               ` Halil Pasic
2022-03-08 15:36                 ` Tony Krowiak
2022-03-08 15:39       ` Jason J. Herne
2022-03-09  0:56         ` Halil Pasic
2022-02-15  0:50 ` [PATCH v18 09/18] s390/vfio-ap: introduce new mutex to control access to the KVM pointer Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 10/18] s390/vfio-ap: allow hot plug/unplug of AP devices when assigned/unassigned Tony Krowiak
2022-03-11 14:26   ` Jason J. Herne
2022-03-11 16:07     ` Tony Krowiak
2022-03-14 13:17       ` Jason J. Herne
2022-03-18 17:30         ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 11/18] s390/vfio-ap: hot plug/unplug of AP devices when probed/removed Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 12/18] s390/vfio-ap: reset queues after adapter/domain unassignment Tony Krowiak
2022-03-15 14:13   ` Jason J. Herne
2022-03-18 17:54     ` Tony Krowiak [this message]
2022-03-18 22:13       ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 13/18] s390/vfio-ap: implement in-use callback for vfio_ap driver Tony Krowiak
2022-03-22 13:13   ` Jason J. Herne
2022-03-22 13:30     ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 14/18] s390/vfio-ap: sysfs attribute to display the guest's matrix Tony Krowiak
2022-03-22 13:22   ` Jason J. Herne
2022-03-22 13:41     ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 15/18] s390/vfio-ap: handle config changed and scan complete notification Tony Krowiak
2022-03-24 14:09   ` Jason J. Herne
2022-03-30 19:26     ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 16/18] s390/vfio-ap: update docs to include dynamic config support Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 17/18] s390/Docs: new doc describing lock usage by the vfio_ap device driver Tony Krowiak
2022-03-31  0:28   ` Halil Pasic
2022-04-04 21:34     ` Tony Krowiak
2022-04-06  8:23       ` Halil Pasic
2022-02-15  0:50 ` [PATCH v18 18/18] MAINTAINERS: pick up all vfio_ap docs for VFIO AP maintainers Tony Krowiak
2022-02-22 19:09 ` [PATCH v18 00/17] s390/vfio-ap: dynamic configuration support Tony Krowiak
2022-02-28 15:53 ` Tony Krowiak
2022-03-02 14:10   ` Jason J. Herne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e869ab58-432e-e451-9021-71ee65488fb0@linux.ibm.com \
    --to=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=fiuczy@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).