Re: [PATCH v4 3/7] s390: zcrypt: driver callback to indicate resource in use

From: Tony Krowiak
Date: Tue Jul 09 2019 - 17:11:29 EST

On 7/9/19 6:49 AM, Cornelia Huck wrote:
On Mon, 8 Jul 2019 10:27:11 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:

On 7/1/19 3:26 PM, Cornelia Huck wrote:
On Wed, 19 Jun 2019 09:04:18 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:

Allow me to first address your fear that a bad actor can hog
resources that can't be removed by root. With this enhancement,
there is nothing preventing a root user from taking resources
from a matrix mdev, it simply forces him/her to follow the
proper procedure. The resources to be removed must first be
unassigned from the matrix mdev to which they are assigned.
The AP bus's /sys/bus/ap/apmask and /sys/bus/ap/aqmask
sysfs attributes can then be edited to transfer ownership
of the resources to zcrypt.

What is the suggested procedure when root wants to unbind a queue
device? Find the mdev using the queue (is that easy enough?), unassign
it, then unbind? Failing to unbind is a bit unexpected; can we point
the admin to the correct mdev from which the queue has to be removed

The proper procedure is to first unassign the adapter, domain, or both
from the mdev to which the APQN is assigned. The difficulty in finding
the queue depends upon how many mdevs have been created. I would expect
that an admin would keep records of who owns what, but in the case he or
she doesn't, it would be a matter of printing out the matrix attribute
of each mdev until you find the mdev to which the APQN is assigned.

Ok, so the information is basically available, if needed.

The only means I know of for informing the admin to which mdev a given
APQN is assigned is to log the error when it occurs.

That might be helpful, if it's easy to do.

I think Matt is
also looking to provide query functions in the management tool on which
he is currently working.

That also sounds helpful.


* It forces the use of the proper procedure to change ownership of AP

This needs to be properly documented, and the admin needs to have a
chance to find out why unbinding didn't work and what needs to be done
(see my comments above).

I will create a section in the vfio-ap.txt document that comes with this
patch set describing the proper procedure for unbinding queues. Of
course, we'll make sure the official IBM doc also more thoroughly
describes this.

+1 for good documentation.

With that, I don't really object to this change.

Then I will make the suggested changes and post v5 to the list.