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
