Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

From: Pierre Morel
Date: Thu Nov 16 2017 - 07:02:50 EST

On 14/11/2017 17:37, Tony Krowiak wrote:
On 11/14/2017 07:40 AM, Cornelia Huck wrote:
On Fri, 13 Oct 2017 13:38:50 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxxxxxxx> wrote:

Introduces a new AP matrix device driver. This device driver
will ultimately perform the following functions:

* Register with the AP bus to let it know that the matrix
ÂÂ driver can control AP queue devices. This will allow
ÂÂ an administrator to unbind an AP queue device from its
ÂÂ device driver and bind it to the matrix device driver.
ÂÂ This is how AP queue devices will be reserved for use
ÂÂ by guest machines.

* Register the matrix device created by the AP matrix bus
ÂÂ with the VFIO mediated device framework. This will create
ÂÂ the sysfs entries needed to create mediated matrix devices.
ÂÂ Each mediated matrix device can be configured with a matrix
ÂÂ of adapters, usage domains and control domains that can be
ÂÂ accessed by a guest machine.

* Process requests via ioctl calls defined for the mediated
ÂÂ matrix device. The guest can access the ioctl calls via
ÂÂ the mediated device's file descriptor to:

ÂÂÂÂ * Grant access to the adapters, usage domains and
ÂÂÂÂÂÂ control domains configured for the mediated matrix
ÂÂÂÂÂÂ device.

This device driver
is built on the VFIO mediated device framework. The VFIO mediated
device framework allows a mediated device to be dedicated exclusively
to a single guest VM.

Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxxxxxxx>
---
 MAINTAINERS | 2 +
 arch/s390/Kconfig | 13 +++
 arch/s390/configs/default_defconfig | 1 +
 arch/s390/configs/gcov_defconfig | 1 +
 arch/s390/configs/performance_defconfig | 1 +
 arch/s390/defconfig | 1 +
 drivers/s390/crypto/Makefile | 6 +-
 drivers/s390/crypto/ap_matrix_bus.c | 8 ++
 drivers/s390/crypto/ap_matrix_bus.h | 2 +-
 drivers/s390/crypto/vfio_ap_matrix_drv.c | 102 ++++++++++++++++++++++++++
 drivers/s390/crypto/vfio_ap_matrix_private.h | 47 ++++++++++++
 11 files changed, 182 insertions(+), 2 deletions(-)
 create mode 100644 drivers/s390/crypto/vfio_ap_matrix_drv.c
 create mode 100644 drivers/s390/crypto/vfio_ap_matrix_private.h

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 48af970..411c19a 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -722,6 +722,19 @@ config VFIO_CCW
ÂÂÂÂÂÂÂ To compile this driver as a module, choose M here: the
ÂÂÂÂÂÂÂ module will be called vfio_ccw.
+config VFIO_AP_MATRIX
+ÂÂÂ def_tristate m
+ÂÂÂ prompt "Support for Adjunct Processor Matrix device interface"
+ÂÂÂ depends on ZCRYPT
+ÂÂÂ select VFIO
+ÂÂÂ select MDEV
+ÂÂÂ select VFIO_MDEV
+ÂÂÂ select VFIO_MDEV_DEVICE
+ÂÂÂ select IOMMU_API
I think the more common pattern is to depend on the VFIO configs
instead of selecting them.
It's ironic because I originally changed from using 'depends on' and changed it based on review comments made
on our internal mailing list. I'll go with 'depends on'.

Is doing like the others a sufficient good reason?
What if the first who did this did not really think about it?

When an administrator configure the kernel what does he think?

- I want to have AP through AP_VFIO in my guests
and he get implicitly VFIO
or
- I want to have VFIO
and he has to explicitly add AP_VFIO too

It seems to me that the first is much more user friendly.

Please tell me if I missed something. dependencies? collateral damages? my logic is wrong?

Regards,

Pierre

..snip...

--
Pierre Morel
Linux/KVM/QEMU in BÃblingen - Germany