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 <[email protected]> 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 <[email protected]>
>>> ---
>>> 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
From 1584127859471909729@xxx Wed Nov 15 10:34:13 +0000 2017
X-GM-THRID: 1581165332668656184
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread