Re: [PATCH v5 06/13] KVM: s390: interfaces to manage guest's AP matrix
From: Pierre Morel
Date: Thu May 24 2018 - 02:54:20 EST
On 23/05/2018 16:29, Tony Krowiak wrote:
On 05/18/2018 04:55 AM, Pierre Morel wrote:
On 16/05/2018 15:48, Tony Krowiak wrote:
On 05/16/2018 09:15 AM, Pierre Morel wrote:
On 16/05/2018 15:12, Tony Krowiak wrote:
On 05/16/2018 03:48 AM, Pierre Morel wrote:
On 15/05/2018 18:07, Tony Krowiak wrote:
On 05/15/2018 10:55 AM, Pierre Morel wrote:
On 07/05/2018 17:11, Tony Krowiak wrote:
Provides interfaces to manage the AP adapters, usage domains
and control domains assigned to a KVM guest.
The guest's SIE state description has a satellite structure
called the
Crypto Control Block (CRYCB) containing three bitmask fields
identifying the adapters, queues (domains) and control domains
assigned to the KVM guest:
...snip...
+}
This function (ap_validate_queue_sharing) only verifies that VM
don't share queues.
What about the queues used by a host application?
How can that be verified from this function? I suppose I could
put a check in here to
verify that the queues are reserved by the vfio_ap device
driver, but that would
be redundant because an AP queue can not be assigned to a
mediated matrix device
via its sysfs attributes unless it is reserved by the vfio_ap
device driver (see
patches 7, 8 and 9).
I understand that you want to implement these checks within
KVM but this is
related to which queue devices are bound to the matrix and
which one are not.
See my comments above and below about AP queue assignment to the
mediated matrix
device. The one verification we can't do when the devices are
assigned is whether
another guest is using the queue because assignment occurs
before the guest using
the queue is started in which case we have no access to KVM. It
makes no sense to
do so at assignment time anyway because it doesn't matter until
the guest using
the mediated matrix device is started, so that check is done in
KVM.
I think that this should be related somehow to the bounded
queue devices and
therefor implemented inside the matrix driver.
As I stated above, when an AP queue is assigned to the mediated
matrix device via
its sysfs attributes, a check is done to verify that it is bound
to the vfio_ap
device driver (see patches 7, 8 and 9). If not, then assignment
will be rejected;
therefore, it will not be possible to configure a CRYCB with AP
queues that are
not bound to the device driver.
This patch and te followed patches take care that the queues are
bound to the
matrix driver when they are assigned to the matrix using the
sysfs entries.
But they do not take care that the queue can not be unbound
before you start
the guest, and they are not in the path if the admin decide to
unbind a queue
at some later time.
That is a good point. I need to put a check in the device driver
at the time
the mediated device fd is opened to verify that the queues being
configured in
the guest's CRYCB are bound to the driver.
not only, you also need to avoid the possibility of unbinding the
device.
For this you need to use the remove callback from the driver.
I thought I addressed this already. The definition of the remove
callback does
not specify a return value, so there is currently no way to prevent
the AP bus
from removing the queue device on unbind. I sent an email to Harald
to discuss
adding a return value to the callback.
If you can not prevent the unbinding you must remove
the according bits in the matrix.
In which matrix? The bits in the matrix configured via the mediated
matrix device's
sysfs attributes files? The bits in the guest's CRYCB? If the latter,
then what happens
to in-process crypto transactions on the guest? Wouldn't this
essentially be like a hot
unplug of the device from the guest?
Obviously from the CRYCB so that the guest do not access to the AP queues
belonging to the AP card anymore.
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in BÃblingen - Germany