From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Morel Subject: Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver Date: Thu, 16 Nov 2017 13:02:26 +0100 Message-ID: References: <1507916344-3896-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1507916344-3896-6-git-send-email-akrowiak@linux.vnet.ibm.com> <20171114134040.3fcd6efd.cohuck@redhat.com> <06ddee4e-e1b8-ba17-5e3e-241e4dcf7cd0@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <06ddee4e-e1b8-ba17-5e3e-241e4dcf7cd0@linux.vnet.ibm.com> Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-Archive: List-Post: To: Tony Krowiak , Cornelia Huck Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, freude@de.ibm.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, borntraeger@de.ibm.com, kwankhede@nvidia.com, bjsdjshi@linux.vnet.ibm.com, pbonzini@redhat.com, alex.williamson@redhat.com, alifm@linux.vnet.ibm.com, mjrosato@linux.vnet.ibm.com, qemu-s390x@nongnu.org, jjherne@linux.vnet.ibm.com, thuth@redhat.com, pasic@linux.vnet.ibm.com List-ID: 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 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 >>> --- >>>   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