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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux