kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Krowiak <akrowiak@linux.ibm.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, freude@linux.ibm.com,
	borntraeger@de.ibm.com, cohuck@redhat.com,
	mjrosato@linux.ibm.com, alex.williamson@redhat.com,
	kwankhede@nvidia.com, fiuczy@linux.ibm.com,
	frankja@linux.ibm.com, david@redhat.com, hca@linux.ibm.com,
	gor@linux.ibm.com
Subject: Re: [PATCH v11 05/14] s390/vfio-ap: implement in-use callback for vfio_ap driver
Date: Mon, 16 Nov 2020 11:58:17 -0500	[thread overview]
Message-ID: <cfa19823-5e75-1d4e-d174-eabaf9541788@linux.ibm.com> (raw)
In-Reply-To: <20201114004722.76c999e0.pasic@linux.ibm.com>



On 11/13/20 6:47 PM, Halil Pasic wrote:
> On Fri, 13 Nov 2020 12:14:22 -0500
> Tony Krowiak <akrowiak@linux.ibm.com> wrote:
> [..]
>>>>    }
>>>>    
>>>> +#define MDEV_SHARING_ERR "Userspace may not re-assign queue %02lx.%04lx " \
>>>> +			 "already assigned to %s"
>>>> +
>>>> +static void vfio_ap_mdev_log_sharing_err(const char *mdev_name,
>>>> +					 unsigned long *apm,
>>>> +					 unsigned long *aqm)
>>>> +{
>>>> +	unsigned long apid, apqi;
>>>> +
>>>> +	for_each_set_bit_inv(apid, apm, AP_DEVICES)
>>>> +		for_each_set_bit_inv(apqi, aqm, AP_DOMAINS)
>>>> +			pr_err(MDEV_SHARING_ERR, apid, apqi, mdev_name);
>>> Isn't error rather severe for this? For my taste even warning would be
>>> severe for this.
>> The user only sees a EADDRINUSE returned from the sysfs interface,
>> so Conny asked if I could log a message to indicate which APQNs are
>> in use by which mdev. I can change this to an info message, but it
>> will be missed if the log level is set higher. Maybe Conny can put in
>> her two cents here since she asked for this.
>>
> I'm looking forward to Conny's opinion. :)
>
> [..]
>>>>    
>>>> @@ -708,18 +732,18 @@ static ssize_t assign_adapter_store(struct device *dev,
>>>>    	if (ret)
>>>>    		goto done;
>>>>    
>>>> -	set_bit_inv(apid, matrix_mdev->matrix.apm);
>>>> +	memset(apm, 0, sizeof(apm));
>>>> +	set_bit_inv(apid, apm);
>>>>    
>>>> -	ret = vfio_ap_mdev_verify_no_sharing(matrix_mdev);
>>>> +	ret = vfio_ap_mdev_verify_no_sharing(matrix_mdev, apm,
>>>> +					     matrix_mdev->matrix.aqm);
>>> What is the benefit of using a copy here? I mean we have the vfio_ap lock
>>> so nobody can see the bit we speculatively flipped.
>> The vfio_ap_mdev_verify_no_sharing() function definition was changed
>> so that it can also be re-used by the vfio_ap_mdev_resource_in_use()
>> function rather than duplicating that code for the in_use callback. The
>> in-use callback is invoked by the AP bus which has no concept of
>> a mediated device, so I made this change to accommodate that fact.
> Seems I was not clear enough with my question. Here you pass a local
> apm which has the every bit 0 except the one corresponding to the
> adapter we are trying to assign. The matrix.apm actually may have
> more apm bits set. What we used to do, is set the matrix.apm bit,
> verify, and clear it if verification fails. I think that
> would still work.
>
> The computational complexity is currently the same. For
> some reason unknown to me ap_apqn_in_matrix_owned_by_def_drv() uses loops
> instead of using bitmap operations. But it won't do any less work
> if the apm argument is sparse. Same is true bitmap ops are used.
>
> What you do here is not wrong, because if the invariants, which should
> be maintained, are maintained, performing the check with the other
> bits set in the apm is superfluous. But as I said before, actually
> it ain't extra work, and if there was a bug, it could help us detect
> it (because the assignment, that should have worked would fail).
>
> Preparing the local apm isn't much extra work either, but I still
> don't understand the change. Why can't you pass in matrix.apm
> after set_bit_inv(apid, ...) like we use to do before?
>
> Again, no big deal, but I just prefer to understand the whys.

I think you misunderstood what I was saying, probably because
I didn't explain it very thoroughly or clearly. The change was not
made to reduce the amount of work done in the
vfio_ap_mdev_verify_no_sharing() function.


If the assignment functions were the only ones to call the
vfio_ap_mdev_verify_no_sharing() function, then you'd be correct;
there would be no good reason not to set the apid in the
matrix_mdev->matrix.apm/aqm as we used to. The modification
was made to accommodate the vfio_ap_mdev_resource_in_use() function.

The vfio_ap_mdev_resource_in_use() function is invoked by the
AP bus when a change is made to the apmask/aqmask that
will result in taking queues away from vfio_ap. This function
needs to verify that the affected APQNs are not assigned to
any matrix mdev. Rather than write a new function that duplicates
the logic in the vfio_ap_mdev_verify_no_sharing() function, I merely
changed the signature to take the apm/aqm specifying the APQNs to
verify rather than obtaining them from the matrix_mdev. The
reason for this is because the bitmaps passed to the in_use
callback are not specific to a particular matrix_mdev as is the
case with the assignment interfaces. Making this change allowed the
vfio_ap_mdev_verify_no_sharing() function to be used by both the
assignment functions as well as the in_use callback.

I suppose another option
would have been to create a phony matrix_mdev in the in_use
callback and copy the masks passed in to the function to the
phony matrix_mdev's apm/aqm. That would have eliminated
the need to change the signature of the vfio_ap_mdev_verify_no_sharing()
function, but I'm not sure it is worth the effort at this point.

>>> I've also pointed out in the previous patch that in_use() isn't
>>> perfectly reliable (at least in theory) because of a race.
>> We discussed that privately and determined that the sysfs assignment
>> interfaces will use mutex_trylock() to avoid races.
> I don't think, what we discussed is going to fix the race I'm referring
> to here. But I do look forward to v12.
>
> Regards,
> Halil


  reply	other threads:[~2020-11-16 16:58 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-22 17:11 [PATCH v11 00/14] s390/vfio-ap: dynamic configuration support Tony Krowiak
2020-10-22 17:11 ` [PATCH v11 01/14] s390/vfio-ap: No need to disable IRQ after queue reset Tony Krowiak
2020-10-22 19:44   ` kernel test robot
2020-10-26 16:57     ` Tony Krowiak
2020-10-27  6:48   ` Halil Pasic
2020-10-29 23:29     ` Tony Krowiak
2020-10-30 16:13       ` Tony Krowiak
2020-10-30 17:27       ` Halil Pasic
2020-10-30 20:45         ` Tony Krowiak
2020-10-30 17:42       ` Halil Pasic
2020-10-30 20:37         ` Tony Krowiak
2020-10-31  3:43           ` Halil Pasic
2020-11-02 14:35             ` Tony Krowiak
2020-10-30 17:54       ` Halil Pasic
2020-10-30 20:53         ` Tony Krowiak
2020-10-30 21:13           ` Tony Krowiak
2020-10-30 17:56       ` Halil Pasic
2020-10-30 21:17         ` Tony Krowiak
2020-10-22 17:11 ` [PATCH v11 02/14] 390/vfio-ap: use new AP bus interface to search for queue devices Tony Krowiak
2020-10-27  7:01   ` Halil Pasic
2020-11-02 21:57     ` Tony Krowiak
2020-10-22 17:11 ` [PATCH v11 03/14] s390/vfio-ap: manage link between queue struct and matrix mdev Tony Krowiak
2020-10-27  9:33   ` Halil Pasic
2020-10-22 17:11 ` [PATCH v11 04/14] s390/zcrypt: driver callback to indicate resource in use Tony Krowiak
2020-10-27 13:01   ` Halil Pasic
2020-10-27 16:55   ` Harald Freudenberger
2020-11-13 21:30     ` Tony Krowiak
2020-11-14  0:00       ` Halil Pasic
2020-11-16 16:23         ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 05/14] s390/vfio-ap: implement in-use callback for vfio_ap driver Tony Krowiak
2020-10-27 13:27   ` Halil Pasic
2020-11-13 17:14     ` Tony Krowiak
2020-11-13 23:47       ` Halil Pasic
2020-11-16 16:58         ` Tony Krowiak [this message]
2020-11-23 17:03         ` Cornelia Huck
2020-11-23 19:23           ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 06/14] s390/vfio-ap: introduce shadow APCB Tony Krowiak
2020-10-28  8:11   ` Halil Pasic
2020-11-13 17:18     ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 07/14] s390/vfio-ap: sysfs attribute to display the guest's matrix Tony Krowiak
2020-10-28  8:17   ` Halil Pasic
2020-11-13 17:27     ` Tony Krowiak
2020-11-13 23:12       ` Halil Pasic
2020-11-19 18:15         ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 08/14] s390/vfio-ap: hot plug/unplug queues on bind/unbind of queue device Tony Krowiak
2020-10-22 20:30   ` kernel test robot
2020-10-26 17:04     ` Tony Krowiak
2020-10-28 13:57   ` Halil Pasic
2020-11-03 22:49     ` Tony Krowiak
2020-11-04 12:52       ` Halil Pasic
2020-11-04 21:20         ` Tony Krowiak
2020-11-05 12:27           ` Halil Pasic
2020-11-13 20:36             ` Tony Krowiak
2020-11-04 13:23       ` Halil Pasic
2020-10-22 17:12 ` [PATCH v11 09/14] s390/vfio-ap: allow assignment of unavailable AP queues to mdev device Tony Krowiak
2020-10-28 15:03   ` Halil Pasic
2020-10-22 17:12 ` [PATCH v11 10/14] s390/vfio-ap: allow hot plug/unplug of AP resources using " Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 11/14] s390/zcrypt: Notify driver on config changed and scan complete callbacks Tony Krowiak
2020-10-27 17:28   ` Harald Freudenberger
2020-11-13 20:58     ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 12/14] s390/vfio-ap: handle host AP config change notification Tony Krowiak
2020-10-22 21:17   ` kernel test robot
2020-10-26 17:07     ` Tony Krowiak
2020-10-26 17:21     ` Tony Krowiak
2020-11-03  9:48   ` kernel test robot
2020-11-13 21:06     ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 13/14] s390/vfio-ap: handle AP bus scan completed notification Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 14/14] s390/vfio-ap: update docs to include dynamic config support Tony Krowiak

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=cfa19823-5e75-1d4e-d174-eabaf9541788@linux.ibm.com \
    --to=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=fiuczy@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@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).