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;
>> }
> ...
>
next prev parent 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).