Re: [PATCH -next] s390/crypto/zcrypt_cex4: convert comma to semicolon

applied to the s390 subsystem. This will go upstream with the next kernel merge window. Thanks On 14.12.20 14:43, Zheng Yongjun wrote: > Replace a comma between expression statements by a semicolon. > > Signed-off-by: Zheng Yongjun > --- > drivers/s390/crypto/zcrypt_cex4.c | 2 +- > 1 file

Re: [PATCH -next] s390/crypto/zcrypt_cex2a: convert comma to semicolon

applied to the s390 subsystem. This will go upstream with the next kernel merge window. Thanks On 14.12.20 14:44, Zheng Yongjun wrote: > Replace a comma between expression statements by a semicolon. > > Signed-off-by: Zheng Yongjun > --- > drivers/s390/crypto/zcrypt_cex2a.c | 2 +- > 1 file

Re: [PATCH 1/1] crypto: Fix possible buffer overflows in pkey_protkey_aes_attr_read

nction the module should trust here. I don't think there is an additional length check needed here. However, Thanks for your contribution. Harald Freudenberger see this function calls another function in the very same file and

Re: [PATCH v12 14/17] s390/zcrypt: Notify driver on config changed and scan complete callbacks

o a bulk >> plug of all affected adapters, domains and control domains into >> affected guests rather than plugging them one at a time when the >> probe callback is invoked. >> >> Please note that changes to the apmask and aqmask do not trigger >> these two c

Re: [PATCH v11 11/14] s390/zcrypt: Notify driver on config changed and scan complete callbacks

k and aqmask do not trigger > these two callbacks since the bus scan function is not invoked by changes > to those masks. > > Signed-off-by: Harald Freudenberger Did I really sign-off this ? I know, I saw this code but ... First of all, please separate the ap bus changes from the vfi

Re: [PATCH v11 04/14] s390/zcrypt: driver callback to indicate resource in use

int queue_depth, int raw_device_type, > int comp_device_type, unsigned int functions); > > +#define APMASKSIZE (BITS_TO_LONGS(AP_DEVICES) * sizeof(unsigned long)) > +#define AQMASKSIZE (BITS_TO_LONGS(AP_DOMAINS) * sizeof(unsigned long)) > + > struct ap_perms { > unsigned long ioctlm[BITS_TO_LONGS(AP_IOCTLS)]; > unsigned long apm[BITS_TO_LONGS(AP_DEVICES)]; I still don't like this code. That's because of what it is doing - not because of the code quality. And Halil, you are right. It is adding more pressure to the mutex used for locking the apmask and aqmask stuff (and the zcrypt multiple device drivers support code also). I am very concerned about the in_use callback which is called with the ap_perms_mutex held AND during bus_for_each_drv (so holding the overall AP BUS mutex) and then diving into the vfio_ap ... with yet another mutex to protect the vfio structs. Reviewed-by: Harald Freudenberger

Re: [PATCH] s390/zcrypt: remove set_fs() invocation in zcrypt device driver

:00:00 2001 From: Harald Freudenberger Date: Thu, 10 Sep 2020 11:32:43 +0200 Subject: [PATCH] s390/zcrypt: remove set_fs() invocation in zcrypt device  driver This patch reworks the zcrypt device driver so that the set_fs() invocation is not needed any more. Instead there is a new flag bool usersp

Re: [PATCH] s390/zcrypt: remove set_fs() invocation in zcrypt device driver

On 11.09.20 08:21, Christoph Hellwig wrote: > On Thu, Sep 10, 2020 at 12:28:38PM +0200, Harald Freudenberger wrote: >> +static inline unsigned long z_copy_from_user(bool userspace, >> + void *to, const void __user *from, >> unsigned lo

[PATCH] s390/zcrypt: remove set_fs() invocation in zcrypt device driver

z_copy_from_user() and z_copy_to_user() which either invoke copy_from_user (userspace is true) or memcpy (userspace is false) the zcrypt dd and the AP bus now has no requirement for the set_fs() functionality any more. Signed-off-by: Harald Freudenberger --- drivers/s390/crypto/zcrypt_api.c | 30

Re: [PATCH] s390/pkey: Remove redundant variable initialization

On 02.08.20 13:15, Tianjia Zhang wrote: > In the first place, the initialization value of `rc` is wrong. > It is unnecessary to initialize `rc` variables, so remove their > initialization operation. > > Fixes: f2bbc96e7cfad ("s390/pkey: add CCA AES cipher key support") &

Re: [PATCH v7 01/15] s390/vfio-ap: store queue struct in hash table for quick access

On 29.04.20 00:30, Tony Krowiak wrote: > > > On 4/28/20 6:57 AM, Harald Freudenberger wrote: >> On 28.04.20 12:07, Halil Pasic wrote: >>> On Mon, 27 Apr 2020 17:48:58 -0400 >>> Tony Krowiak wrote: >>> >>>> On 4/27/20 11:17 AM, Halil

Re: [PATCH v7 03/15] s390/zcrypt: driver callback to indicate resource in use

On 28.04.20 00:24, Tony Krowiak wrote: > > > On 4/27/20 4:20 AM, Pierre Morel wrote: >> >> >> On 2020-04-07 21:20, Tony Krowiak wrote: >>> Introduces a new driver callback to prevent a root user from unbinding >>> an AP queue from its device driver if the queue is in use. The intent of >>> this

Re: [PATCH v7 01/15] s390/vfio-ap: store queue struct in hash table for quick access

On 28.04.20 12:07, Halil Pasic wrote: > On Mon, 27 Apr 2020 17:48:58 -0400 > Tony Krowiak wrote: > >> >> On 4/27/20 11:17 AM, Halil Pasic wrote: >>> On Mon, 27 Apr 2020 15:05:23 +0200 >>> Harald Freudenberger wrote: >>> >>>> On 24.04.

Re: [PATCH v7 01/15] s390/vfio-ap: store queue struct in hash table for quick access

On 27.04.20 17:17, Halil Pasic wrote: > On Mon, 27 Apr 2020 15:05:23 +0200 > Harald Freudenberger wrote: > >> On 24.04.20 05:57, Halil Pasic wrote: >>> On Tue, 7 Apr 2020 15:20:01 -0400 >>> Tony Krowiak wrote: >>> >>>> Rather th

Re: [PATCH] s390/zcrypt: remove the exporting of ap_query_configuration

r KVM code. However, never used. So removing the export is the right thing. Thanks Denis Heiko/Vasily will you pick this patch please? Reviewed-by: Harald Freudenberger

Re: [PATCH v4 5/7] s390: vfio-ap: allow assignment of unavailable AP resources to mdev device

On 17.06.19 17:07, Tony Krowiak wrote: > On 6/17/19 6:05 AM, Harald Freudenberger wrote: >> On 13.06.19 21:39, Tony Krowiak wrote: >>> The AP architecture does not preclude assignment of AP resources that are >>> not available. Let's go ahead and implement this facet

Re: [PATCH v4 7/7] s390: vfio-ap: update documentation

On 13.06.19 21:39, Tony Krowiak wrote: > This patch updates the vfio-ap documentation to include the information > below. > > Changes made to the mdev matrix assignment interfaces: > > * Allow assignment of APQNs that are not bound to the vfio-ap device > driver as long as they are not owned by

Re: [PATCH v4 5/7] s390: vfio-ap: allow assignment of unavailable AP resources to mdev device

On 13.06.19 21:39, Tony Krowiak wrote: > The AP architecture does not preclude assignment of AP resources that are > not available. Let's go ahead and implement this facet of the AP > architecture for linux guests. > > The current implementation does not allow assignment of AP adapters or >

Re: [PATCH v4 3/7] s390: zcrypt: driver callback to indicate resource in use

On 13.06.19 21:39, Tony Krowiak wrote: > Introduces a new driver callback to prevent a root user from unbinding > an AP queue from its device driver if the queue is in use. This prevents > a root user from inadvertently taking a queue away from a guest and > giving it to the host, or vice versa.

Re: [PATCH v4 2/7] s390: vfio-ap: wait for queue empty on queue reset

On 13.06.19 21:39, Tony Krowiak wrote: > Refactors the AP queue reset function to wait until the queue is empty > after the PQAP(ZAPQ) instruction is executed to zero out the queue as > required by the AP architecture. > > Signed-off-by: Tony Krowiak > --- > drivers/s390/crypto/vfio_ap_ops.c |

Re: [PATCH v4 1/7] s390: vfio-ap: Refactor vfio_ap driver probe and remove callbacks

On 13.06.19 21:39, Tony Krowiak wrote: > In order to limit the number of private mdev functions called from the > vfio_ap device driver as well as to provide a landing spot for dynamic > configuration code related to binding/unbinding AP queue devices to/from > the vfio_ap driver, the following

Re: [PATCH v9 4/4] s390: ap: kvm: Enable PQAP/AQIC facility for the guest

n Control */ > 156, /* etoken facility */ > -1 /* END */ > } acked-by: Harald Freudenberger

Re: [PATCH v9 3/4] s390: ap: implement PAPQ AQIC interception in kernel

rypto.pqap_hook = NULL; > + vfio_ap_mdev_reset_queues(mdev); > + kvm_put_kvm(matrix_mdev->kvm); > + matrix_mdev->kvm = NULL; > + } > + mutex_unlock(_dev->lock); > > - vfio_ap_mdev_reset_queues(mdev); > vfio_unregister_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY, >_mdev->iommu_notifier); > vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY, >_mdev->group_notifier); > - matrix_mdev->kvm = NULL; > module_put(THIS_MODULE); > } > > @@ -941,6 +1263,7 @@ static ssize_t vfio_ap_mdev_ioctl(struct mdev_device > *mdev, > { > int ret; > > + mutex_lock(_dev->lock); > switch (cmd) { > case VFIO_DEVICE_GET_INFO: > ret = vfio_ap_mdev_get_device_info(arg); > @@ -952,6 +1275,7 @@ static ssize_t vfio_ap_mdev_ioctl(struct mdev_device > *mdev, > ret = -EOPNOTSUPP; > break; > } > + mutex_unlock(_dev->lock); > > return ret; > } > diff --git a/drivers/s390/crypto/vfio_ap_private.h > b/drivers/s390/crypto/vfio_ap_private.h > index 18dcc4d..f46dde5 100644 > --- a/drivers/s390/crypto/vfio_ap_private.h > +++ b/drivers/s390/crypto/vfio_ap_private.h > @@ -4,6 +4,7 @@ > * > * Author(s): Tony Krowiak > * Halil Pasic > + * Pierre Morel > * > * Copyright IBM Corp. 2018 > */ > @@ -89,5 +90,15 @@ struct ap_matrix_mdev { > > extern int vfio_ap_mdev_register(void); > extern void vfio_ap_mdev_unregister(void); > +int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi, > + unsigned int retry); > > +struct vfio_ap_queue { > + struct ap_matrix_mdev *matrix_mdev; > + unsigned long saved_pfn; > + int apqn; > +#define VFIO_AP_ISC_INVALID 0xff > + unsigned char saved_isc; > +}; > +struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q); > #endif /* _VFIO_AP_PRIVATE_H_ */ acked-by: Harald Freudenberger

Re: [PATCH v9 2/4] vfio: ap: register IOMMU VFIO notifier

t; +++ b/drivers/s390/crypto/vfio_ap_private.h > @@ -81,8 +81,10 @@ struct ap_matrix_mdev { > struct list_head node; > struct ap_matrix matrix; > struct notifier_block group_notifier; > + struct notifier_block iommu_notifier; > struct kvm *kvm; > struct kvm_s390_module_hook pqap_hook; > + struct mdev_device *mdev; > }; > > extern int vfio_ap_mdev_register(void); acked-by: Harald Freudenberger

Re: [PATCH v9 1/4] s390: ap: kvm: add PQAP interception for AQIC

{ > int rc; > @@ -878,6 +962,8 @@ int kvm_s390_handle_b2(struct kvm_vcpu *vcpu) > return handle_sthyi(vcpu); > case 0x7d: > return handle_stsi(vcpu); > + case 0xaf: > + return handle_pqap(vcpu); > case 0xb1: > return handle_stfl(vcpu); > case 0xb2: > diff --git a/drivers/s390/crypto/vfio_ap_private.h > b/drivers/s390/crypto/vfio_ap_private.h > index 76b7f98..a910be1 100644 > --- a/drivers/s390/crypto/vfio_ap_private.h > +++ b/drivers/s390/crypto/vfio_ap_private.h > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > > #include "ap_bus.h" > > @@ -81,6 +82,7 @@ struct ap_matrix_mdev { > struct ap_matrix matrix; > struct notifier_block group_notifier; > struct kvm *kvm; > + struct kvm_s390_module_hook pqap_hook; > }; > > extern int vfio_ap_mdev_register(void); acked-by: Harald Freudenberger

Re: [RFC PATCH 27/57] drivers: Unify the match prototype for bus_find_device with class_find_device

ers with class_find_device() users. > > Cc: Alexander Shishkin > Cc: Wolfram Sang > Cc: Jonathan Cameron > Cc: Hartmut Knaack > Cc: Grygorii Strashko > Cc: "David S. Miller" > Cc: Bjorn Helgaas > Cc: Sebastian Ott > Cc: Peter Oberparleiter > Cc: Hara

Re: [RFC PATCH 37/57] drivers: s390: zcrypt: Use class_find_device_by_devt helper

On 03.06.19 17:50, Suzuki K Poulose wrote: > Use the generic helper to find a device matching the devt. > > Cc: Harald Freudenberger > Cc: Heiko Carstens > Signed-off-by: Suzuki K Poulose > --- > drivers/s390/crypto/zcrypt_api.c | 11 +-- > 1 file changed, 1 in

Re: [RFC PATCH 32/57] drivers: s390-crypto: Use class_device_find_by_name() helper

On 03.06.19 17:49, Suzuki K Poulose wrote: > Use the new class_find_device_by_name() helper. > > Cc: Harald Freudenberger > Cc: Martin Schwidefsky > Cc: Heiko Carstens > Signed-off-by: Suzuki K Poulose > --- > drivers/s390/crypto/zcrypt_api.c | 12 ++-- > 1

Re: [RFC PATCH 1/2] crypto: Allow working with key references

hanks for the pointer. > So the preferred way is defining a new crypto algorithm prefixed with > "p" and reusing setkey to provide the key reference. The "p" in paes is because we call it "protected key aes". I think you are not limited to the "p". What Herbert tries to point out is that you may define your own cipher with an unique name and there you can handle your secure key references as you like. You may use the s390 paes implementation as a starting point. regards Harald Freudenberger > > Thanks, > //richard >

Re: [PATCH v1] s390/pkey: Use -ENODEV instead of -EOPNOTSUPP

load the pkey module because of missing HW functionality. > > Cc: Harald Freudenberger > Cc: Heiko Carstens > Cc: Cornelia Huck > Cc: Christian Borntraeger > Signed-off-by: David Hildenbrand > --- > drivers/s390/crypto/pkey_api.c | 6 +++--- > 1 file changed, 3 insertion

Re: [PATCH 6/7] s390: vfio-ap: handle dynamic config/deconfig of AP adapter

On 11.04.19 23:03, Tony Krowiak wrote: > Once an APQN is assigned to an mdev device it will remained assigned until > it is explicitly unassigned from the mdev device. The associated AP queue > devices, however, can come and go due to failures or deliberate actions by > a sysadmin. For example, a

Re: [PATCH 1/7] s390: zcrypt: driver callback to indicate resource in use

On 11.04.19 23:03, Tony Krowiak wrote: > Introduces a new driver callback to prevent a root user from unbinding > an AP queue from its device driver if the queue is in use. This prevents > a root user from inadvertently taking a queue away from a guest and > giving it to the host, or vice versa.

Re: [PATCH 05/12] s390: zcrypt: initialize variables before_use

-EFAULT; > goto out_free; > } Thanks Arnd, but as Nathan already wrote, I'd prefer to have the variable initialized with 0 instead of -1. If you agree with this, I'll rewrite the patch and apply it to our internal git and it will appear at kernel org with the next s390 code merge then. regards Harald Freudenberger

Re: [PATCH v6 2/7] s390: ap: new vfio_ap_queue structure

On 26.03.19 21:45, Tony Krowiak wrote: > On 3/22/19 10:43 AM, Pierre Morel wrote: >> The AP interruptions are assigned on a queue basis and >> the GISA structure is handled on a VM basis, so that >> we need to add a structure we can retrieve from both side > > s/side/sides/ > >> holding the

Re: [PATCH v6 2/7] s390: ap: new vfio_ap_queue structure

On 22.03.19 15:43, Pierre Morel wrote: > The AP interruptions are assigned on a queue basis and > the GISA structure is handled on a VM basis, so that > we need to add a structure we can retrieve from both side > holding the information we need to handle PQAP/AQIC interception > and setup the

Re: [PATCH] zcrypt: handle AP Info notification from CHSC SEI command

On 30.01.19 19:32, Sebastian Ott wrote: > On Wed, 30 Jan 2019, Tony Krowiak wrote: >> +#if IS_ENABLED(CONFIG_ZCRYPT) >> +void ap_bus_cfg_chg(void); >> +#else >> +#error "no CONFIG_ZCRYPT" >^ > I don't think that's the right thing to do here. > > >> +++ b/drivers/s390/cio/chsc.h >> @@ -9,6 +9,7

Re: [PATCH v2 1/1] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem

On 21.02.19 08:37, Christian Borntraeger wrote: > > On 20.02.2019 14:12, Harald Freudenberger wrote: >> On 18.02.19 19:08, Pierre Morel wrote: >>> Libudev relies on having a subsystem link for non-root devices. To >>> avoid libudev (and potentially other userspace to

Re: [PATCH v2 1/1] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem

code because of disability of userspace code. Hm, you are switching root cause and effect. However, not my job. Why do you need this dummy bus ? Did you evaluate using a "class" subsystem instead ? This is very common and my assumption is that libudev is able to handle this. I am using a "zcrypt" class for providing additional zcrypt device nodes and this works fine together with udev. I would avoid the introduction and maintenance of bus code at any cost. Btw. having a look onto the naming ... the module is named "vfio_ap", the driver is named "vfio_ap", the bus is named "vfio_ap", the root bus device is named "vfio_ap" ... a bunch of vfio_aps naming different things. regards Harald Freudenberger

Re: [PATCH] zcrypt: handle AP Info notification from CHSC SEI command

On 01.02.19 15:35, Cornelia Huck wrote: > On Thu, 31 Jan 2019 18:50:57 -0500 > Tony Krowiak wrote: > >> On 1/31/19 4:55 AM, Cornelia Huck wrote: >>> On Wed, 30 Jan 2019 12:48:46 -0500 >>> Tony Krowiak wrote: >>> Two questions: >>> - Does the event cover _any_ change to the AP configuration, or

Re: [PATCH] zcrypt: handle AP Info notification from CHSC SEI command

On 01.02.19 16:38, Tony Krowiak wrote: > On 2/1/19 4:01 AM, Heiko Carstens wrote: >> On Thu, Jan 31, 2019 at 06:28:39PM -0500, Tony Krowiak wrote: >>> On 1/30/19 1:32 PM, Sebastian Ott wrote: On Wed, 30 Jan 2019, Tony Krowiak wrote: > +#if IS_ENABLED(CONFIG_ZCRYPT) > +void

Re: [PATCH v11 26/26] s390: doc: detailed specifications for AP virtualization

ontrol_domain >> + sysfs file. >> + >> + If a mistake is made configuring an adapter, domain or control domain, >> + you can use the unassign_xxx files to unassign the adapter, domain or >> + control domain. >> + >> + To display the matrix configuration for Guest1: >> + >> + cat matrix >> + >> + This is how the matrix is configured for Guest2: >> + >> + echo 5 > assign_adapter >> + echo 0x47 > assign_domain >> + echo 0xff > assign_domain >> + >> + This is how the matrix is configured for Guest3: >> + >> + echo 6 > assign_adapter >> + echo 0x47 > assign_domain >> + echo 0xff > assign_domain >> + > I'm curious why this interface didn't adopt the +/- notation invented > above for consistency. Too difficult to do rollbacks with a string on > entries? > > Looks pretty reasonable other than the points of confusion noted. > Thanks, > > Alex > Hello Alex the AP bus  apmask and aqmask interface is not part of this patch series. It's a general concept not only related to KVM and vfio but may be used (and will) by other kernel and userspace features. The bit ordering follows other implementations in the s390 (big endian) realm where bit counting starts with 0 on the very left side and increases to the right. All the AP bus stuff obeys to this (maybe historical) scheme. Please have a look on the patches which introduced this mask API: - s390/zcrypt: AP bus support for alternate driver(s) : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e0bdbe5c21cb8316a694e46ad5aad339f6894a6 - s390/zcrypt: hex string mask improvements for apmask and aqmask: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3d8f60d38e249f989a7fca9c2370c31c3d5487e1 The patch headers should describe the behavior and the syntax of the recognized string patterns in more detail. regards Harald Freudenberger (maintainer of the s390 AP bus and zcrypt device driver code)

Re: [PATCH v11 26/26] s390: doc: detailed specifications for AP virtualization

ontrol_domain >> + sysfs file. >> + >> + If a mistake is made configuring an adapter, domain or control domain, >> + you can use the unassign_xxx files to unassign the adapter, domain or >> + control domain. >> + >> + To display the matrix configuration for Guest1: >> + >> + cat matrix >> + >> + This is how the matrix is configured for Guest2: >> + >> + echo 5 > assign_adapter >> + echo 0x47 > assign_domain >> + echo 0xff > assign_domain >> + >> + This is how the matrix is configured for Guest3: >> + >> + echo 6 > assign_adapter >> + echo 0x47 > assign_domain >> + echo 0xff > assign_domain >> + > I'm curious why this interface didn't adopt the +/- notation invented > above for consistency. Too difficult to do rollbacks with a string on > entries? > > Looks pretty reasonable other than the points of confusion noted. > Thanks, > > Alex > Hello Alex the AP bus  apmask and aqmask interface is not part of this patch series. It's a general concept not only related to KVM and vfio but may be used (and will) by other kernel and userspace features. The bit ordering follows other implementations in the s390 (big endian) realm where bit counting starts with 0 on the very left side and increases to the right. All the AP bus stuff obeys to this (maybe historical) scheme. Please have a look on the patches which introduced this mask API: - s390/zcrypt: AP bus support for alternate driver(s) : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e0bdbe5c21cb8316a694e46ad5aad339f6894a6 - s390/zcrypt: hex string mask improvements for apmask and aqmask: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3d8f60d38e249f989a7fca9c2370c31c3d5487e1 The patch headers should describe the behavior and the syntax of the recognized string patterns in more detail. regards Harald Freudenberger (maintainer of the s390 AP bus and zcrypt device driver code)

Re: [PATCH v10 13/26] s390: vfio-ap: zeroize the AP queues

On 24.09.2018 14:16, Halil Pasic wrote: > > On 09/24/2018 01:36 PM, Cornelia Huck wrote: >> On Wed, 12 Sep 2018 15:43:03 -0400 >> Tony Krowiak wrote: >> >>> From: Tony Krowiak >>> >>> Let's call PAPQ(ZAPQ) to zeroize a queue for each queue configured >>> for a mediated matrix device when it is

Re: [PATCH v10 13/26] s390: vfio-ap: zeroize the AP queues

On 24.09.2018 14:16, Halil Pasic wrote: > > On 09/24/2018 01:36 PM, Cornelia Huck wrote: >> On Wed, 12 Sep 2018 15:43:03 -0400 >> Tony Krowiak wrote: >> >>> From: Tony Krowiak >>> >>> Let's call PAPQ(ZAPQ) to zeroize a queue for each queue configured >>> for a mediated matrix device when it is

Re: [PATCH v10 06/26] s390: vfio-ap: sysfs interfaces to configure adapters

On 21.09.2018 11:40, Cornelia Huck wrote: > On Wed, 12 Sep 2018 15:42:56 -0400 > Tony Krowiak wrote: > >> From: Tony Krowiak >> >> Introduces two new sysfs attributes for the VFIO mediated >> matrix device for assigning AP adapters to and unassigning >> AP adapters from a mediated matrix device.

Re: [PATCH v10 06/26] s390: vfio-ap: sysfs interfaces to configure adapters

On 21.09.2018 11:40, Cornelia Huck wrote: > On Wed, 12 Sep 2018 15:42:56 -0400 > Tony Krowiak wrote: > >> From: Tony Krowiak >> >> Introduces two new sysfs attributes for the VFIO mediated >> matrix device for assigning AP adapters to and unassigning >> AP adapters from a mediated matrix device.

Re: [GIT PULL] s390 patches for the 4.19 merge window #2

On 05.09.2018 02:16, Kees Cook wrote: > On Fri, Aug 24, 2018 at 12:42 AM, Martin Schwidefsky > wrote: >> Harald Freudenberger (5): >> s390/zcrypt: hex string mask improvements for apmask and aqmask. > This (and an earlier 2017 commit) adds VLAs, which are being > re

Re: [GIT PULL] s390 patches for the 4.19 merge window #2

On 05.09.2018 02:16, Kees Cook wrote: > On Fri, Aug 24, 2018 at 12:42 AM, Martin Schwidefsky > wrote: >> Harald Freudenberger (5): >> s390/zcrypt: hex string mask improvements for apmask and aqmask. > This (and an earlier 2017 commit) adds VLAs, which are being > re

Re: [PATCH v9 22/22] s390: doc: detailed specifications for AP virtualization

to have an empty control domain mask and the guest should be able to run crypto CPRBs on the usage domain(s) without any problems. However, nobody has tried this. regards Harald Freudenberger

Re: [PATCH v9 22/22] s390: doc: detailed specifications for AP virtualization

to have an empty control domain mask and the guest should be able to run crypto CPRBs on the usage domain(s) without any problems. However, nobody has tried this. regards Harald Freudenberger

Re: [PATCH v9 22/22] s390: doc: detailed specifications for AP virtualization

On 21.08.2018 17:53, Cornelia Huck wrote: > On Tue, 21 Aug 2018 11:00:00 +0200 > Harald Freudenberger wrote: > >> On 20.08.2018 18:03, Cornelia Huck wrote: >>> On Mon, 13 Aug 2018 17:48:19 -0400 >>> Tony Krowiak wrote: >>>> +* AP Instructions: &

Re: [PATCH v9 22/22] s390: doc: detailed specifications for AP virtualization

On 21.08.2018 17:53, Cornelia Huck wrote: > On Tue, 21 Aug 2018 11:00:00 +0200 > Harald Freudenberger wrote: > >> On 20.08.2018 18:03, Cornelia Huck wrote: >>> On Mon, 13 Aug 2018 17:48:19 -0400 >>> Tony Krowiak wrote: >>>> +* AP Instructions: &

Re: [PATCH v9 22/22] s390: doc: detailed specifications for AP virtualization

On 20.08.2018 18:03, Cornelia Huck wrote: > On Mon, 13 Aug 2018 17:48:19 -0400 > Tony Krowiak wrote: > >> From: Tony Krowiak >> >> This patch provides documentation describing the AP architecture and >> design concepts behind the virtualization of AP devices. It also >> includes an example of

Re: [PATCH v9 22/22] s390: doc: detailed specifications for AP virtualization

On 20.08.2018 18:03, Cornelia Huck wrote: > On Mon, 13 Aug 2018 17:48:19 -0400 > Tony Krowiak wrote: > >> From: Tony Krowiak >> >> This patch provides documentation describing the AP architecture and >> design concepts behind the virtualization of AP devices. It also >> includes an example of

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

. - >From 9e050f843f3281da1f65292422e30f2dd1fd6d98 Mon Sep 17 00:00:00 2001 From: Harald Freudenberger Date: Thu, 9 Aug 2018 11:59:34 +0200 Subject: [PATCH] s390/zcrypt: fix ap_instructions_available() returncodes During review of KVM patches it was complained that the ap_instructions_availa

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

. - >From 9e050f843f3281da1f65292422e30f2dd1fd6d98 Mon Sep 17 00:00:00 2001 From: Harald Freudenberger Date: Thu, 9 Aug 2018 11:59:34 +0200 Subject: [PATCH] s390/zcrypt: fix ap_instructions_available() returncodes During review of KVM patches it was complained that the ap_instructions_availa

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

On 10.08.2018 10:49, Cornelia Huck wrote: > On Thu, 9 Aug 2018 12:06:56 -0400 > Tony Krowiak wrote: > >> On 08/09/2018 05:17 AM, Harald Freudenberger wrote: >>> On 09.08.2018 11:06, Cornelia Huck wrote: >>>> On Wed, 8 Aug 2018 10:44:14 -0400 >>>>

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

On 10.08.2018 10:49, Cornelia Huck wrote: > On Thu, 9 Aug 2018 12:06:56 -0400 > Tony Krowiak wrote: > >> On 08/09/2018 05:17 AM, Harald Freudenberger wrote: >>> On 09.08.2018 11:06, Cornelia Huck wrote: >>>> On Wed, 8 Aug 2018 10:44:14 -0400 >>>>

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

Here is now a reworked version of the integrate ap_asm.h into include/asm/ap.h patch which can be used to apply it within the AP virtualisation patch queue for testing: >From c81710e7cd073c4f9a904f3539ecf17fd89c9c2d Mon Sep 17 00:00:00 2001 From: Harald Freudenberger Date: Tue, 12 Jun 2018

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

Here is now a reworked version of the integrate ap_asm.h into include/asm/ap.h patch which can be used to apply it within the AP virtualisation patch queue for testing: >From c81710e7cd073c4f9a904f3539ecf17fd89c9c2d Mon Sep 17 00:00:00 2001 From: Harald Freudenberger Date: Tue, 12 Jun 2018

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

On 09.08.2018 11:06, Cornelia Huck wrote: > On Wed, 8 Aug 2018 10:44:14 -0400 > Tony Krowiak wrote: > >> From: Harald Freudenberger >> >> Move all the inline functions from the ap bus header >> file ap_asm.h into the in-kernel api header file >> arch/s39

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

On 09.08.2018 11:06, Cornelia Huck wrote: > On Wed, 8 Aug 2018 10:44:14 -0400 > Tony Krowiak wrote: > >> From: Harald Freudenberger >> >> Move all the inline functions from the ap bus header >> file ap_asm.h into the in-kernel api header file >> arch/s39

Re: [PATCH v8 21/22] KVM: s390: CPU model support for AP virtualization

On 09.08.2018 10:17, David Hildenbrand wrote: > On 08.08.2018 16:44, Tony Krowiak wrote: >> From: Tony Krowiak >> >> Introduces a new CPU model feature and two CPU model >> facilities to support AP virtualization for KVM guests. >> >> CPU model feature: >> >> The KVM_S390_VM_CPU_FEAT_AP feature

Re: [PATCH v8 21/22] KVM: s390: CPU model support for AP virtualization

On 09.08.2018 10:17, David Hildenbrand wrote: > On 08.08.2018 16:44, Tony Krowiak wrote: >> From: Tony Krowiak >> >> Introduces a new CPU model feature and two CPU model >> facilities to support AP virtualization for KVM guests. >> >> CPU model feature: >> >> The KVM_S390_VM_CPU_FEAT_AP feature

Re: [PATCH] s390/ap_bus: replace PTR_RET with PTR_ERR_OR_ZERO

42,7 @@ static int __init ap_module_init(void) > > /* Create /sys/devices/ap. */ > ap_root_device = root_device_register("ap"); > - rc = PTR_RET(ap_root_device); > + rc = PTR_ERR_OR_ZERO(ap_root_device); > if (rc) > goto out_bus; > Reviewed-by: Harald Freudenberger

Re: [PATCH] s390/ap_bus: replace PTR_RET with PTR_ERR_OR_ZERO

42,7 @@ static int __init ap_module_init(void) > > /* Create /sys/devices/ap. */ > ap_root_device = root_device_register("ap"); > - rc = PTR_RET(ap_root_device); > + rc = PTR_ERR_OR_ZERO(ap_root_device); > if (rc) > goto out_bus; > Reviewed-by: Harald Freudenberger

Re: [PATCH v6 08/21] s390: vfio-ap: register matrix device with VFIO mdev framework

On 09.07.2018 16:17, Pierre Morel wrote: > On 29/06/2018 23:11, Tony Krowiak wrote: >> Registers the matrix device created by the VFIO AP device >> driver with the VFIO mediated device framework. >> Registering the matrix device will create the sysfs >> structures needed to create mediated matrix

Re: [PATCH v6 08/21] s390: vfio-ap: register matrix device with VFIO mdev framework

On 09.07.2018 16:17, Pierre Morel wrote: > On 29/06/2018 23:11, Tony Krowiak wrote: >> Registers the matrix device created by the VFIO AP device >> driver with the VFIO mediated device framework. >> Registering the matrix device will create the sysfs >> structures needed to create mediated matrix

Re: [PATCH v6 21/21] s390: doc: detailed specifications for AP virtualization

On 03.07.2018 16:56, Tony Krowiak wrote: > On 07/03/2018 03:46 AM, Harald Freudenberger wrote: >> On 02.07.2018 18:28, Halil Pasic wrote: >>> >>> On 06/29/2018 11:11 PM, Tony Krowiak wrote: >>>> This patch provides documentation describing the AP archi

Re: [PATCH v6 21/21] s390: doc: detailed specifications for AP virtualization

On 03.07.2018 16:56, Tony Krowiak wrote: > On 07/03/2018 03:46 AM, Harald Freudenberger wrote: >> On 02.07.2018 18:28, Halil Pasic wrote: >>> >>> On 06/29/2018 11:11 PM, Tony Krowiak wrote: >>>> This patch provides documentation describing the AP archi

Re: [PATCH v6 21/21] s390: doc: detailed specifications for AP virtualization

On 29.06.2018 23:11, Tony Krowiak wrote: > This patch provides documentation describing the AP architecture and > design concepts behind the virtualization of AP devices. It also > includes an example of how to configure AP devices for exclusive > use of KVM guests. > > Signed-off-by: Tony Krowiak

Re: [PATCH v6 21/21] s390: doc: detailed specifications for AP virtualization

On 29.06.2018 23:11, Tony Krowiak wrote: > This patch provides documentation describing the AP architecture and > design concepts behind the virtualization of AP devices. It also > includes an example of how to configure AP devices for exclusive > use of KVM guests. > > Signed-off-by: Tony Krowiak

Re: [PATCH v6 21/21] s390: doc: detailed specifications for AP virtualization

On 02.07.2018 18:28, Halil Pasic wrote: > > > On 06/29/2018 11:11 PM, Tony Krowiak wrote: >> This patch provides documentation describing the AP architecture and >> design concepts behind the virtualization of AP devices. It also >> includes an example of how to configure AP devices for exclusive

Re: [PATCH v6 21/21] s390: doc: detailed specifications for AP virtualization

On 02.07.2018 18:28, Halil Pasic wrote: > > > On 06/29/2018 11:11 PM, Tony Krowiak wrote: >> This patch provides documentation describing the AP architecture and >> design concepts behind the virtualization of AP devices. It also >> includes an example of how to configure AP devices for exclusive

Re: [PATCH v5 01/13] KVM: s390: Interface to test whether APXA installed

>> patch). > > I'll check with the developer. The proposal is out on the internal mailing list. I'd like to release it (internal) tomorrow or start next week. Already talked with Christian about this because we need to align it somehow with kvm and s390 kernel development. regards H

Re: [PATCH v5 01/13] KVM: s390: Interface to test whether APXA installed

eck with the developer. The proposal is out on the internal mailing list. I'd like to release it (internal) tomorrow or start next week. Already talked with Christian about this because we need to align it somehow with kvm and s390 kernel development. regards Harald Freudenberger >

Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys

f key token as a binary blob. I am also open to use the kernel key ring for future extensions. But please understand we needed a way to support our hardware keys and I think the chosen design isn't so bad. regards Harald Freudenberger using the kernel key ring in future extensions.

Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys

f key token as a binary blob. I am also open to use the kernel key ring for future extensions. But please understand we needed a way to support our hardware keys and I think the chosen design isn't so bad. regards Harald Freudenberger using the kernel key ring in future extensions.

Re: [PATCH v2 03/15] s390: zcrypt: externalize AP instructions available function

On 02/28/2018 06:41 PM, Cornelia Huck wrote: > On Tue, 27 Feb 2018 09:28:01 -0500 > Tony Krowiak wrote: > >> If the AP instructions are not available on the linux host, then >> AP devices can not be interpreted by the SIE. The AP bus has a >> function it uses to

Re: [PATCH v2 03/15] s390: zcrypt: externalize AP instructions available function

On 02/28/2018 06:41 PM, Cornelia Huck wrote: > On Tue, 27 Feb 2018 09:28:01 -0500 > Tony Krowiak wrote: > >> If the AP instructions are not available on the linux host, then >> AP devices can not be interpreted by the SIE. The AP bus has a >> function it uses to determine if the AP instructions

Re: [PATCH v2 03/15] s390: zcrypt: externalize AP instructions available function

; > +} > +EXPORT_SYMBOL(ap_instructions_installed); > + > /** > * ap_init_configuration(): Allocate and query configuration array. > */ Reviewed-by: Harald Freudenberger <fre...@linux.vnet.ibm.com>

Re: [PATCH v2 03/15] s390: zcrypt: externalize AP instructions available function

gt; @@ -211,6 +211,12 @@ int ap_query_configuration(struct ap_config_info *info) > } > EXPORT_SYMBOL(ap_query_configuration); > > +int ap_instructions_installed(void) > +{ > + return (ap_instructions_available() == 0); > +} > +EXPORT_SYMBOL(ap_instructions_installed); > + > /** > * ap_init_configuration(): Allocate and query configuration array. > */ Reviewed-by: Harald Freudenberger

Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest

On 12/02/2017 02:30 AM, Tony Krowiak wrote: > On 11/03/2017 04:47 AM, Christian Borntraeger wrote: >> >> On 11/02/2017 07:49 PM, Tony Krowiak wrote: >>> On 11/02/2017 11:53 AM, Christian Borntraeger wrote: On 11/02/2017 04:36 PM, Tony Krowiak wrote: > On 11/02/2017 08:08 AM, Christian

Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest

On 12/02/2017 02:30 AM, Tony Krowiak wrote: > On 11/03/2017 04:47 AM, Christian Borntraeger wrote: >> >> On 11/02/2017 07:49 PM, Tony Krowiak wrote: >>> On 11/02/2017 11:53 AM, Christian Borntraeger wrote: On 11/02/2017 04:36 PM, Tony Krowiak wrote: > On 11/02/2017 08:08 AM, Christian

Re: [PATCH] s390/pkey: fix kzalloc-simple.cocci warnings

On 10/11/2017 09:52 PM, Vasyl Gomonovych wrote: > drivers/s390/crypto/pkey_api.c:128:11-18: WARNING: kzalloc should be used for > cprbmem, instead of kmalloc/memset > > Use kzalloc rather than kmalloc followed by memset with 0 > > Generated by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci >

Re: [PATCH] s390/pkey: fix kzalloc-simple.cocci warnings

On 10/11/2017 09:52 PM, Vasyl Gomonovych wrote: > drivers/s390/crypto/pkey_api.c:128:11-18: WARNING: kzalloc should be used for > cprbmem, instead of kmalloc/memset > > Use kzalloc rather than kmalloc followed by memset with 0 > > Generated by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci >

Re: [PATCH] s390/zcrypt: make CPRBX const

* + 0x000A 'MRP ' (MCL3 'PK' or CEX2C 'PK') > * - VUD block > */ > -static struct CPRBX static_cprbx = { > +static const struct CPRBX static_cprbx = { > .cprb_len = 0x00DC, > .cprb_ver_id= 0x02, > .func_id= {0x54, 0x32}, Applied. Will

Re: [PATCH] s390/zcrypt: make CPRBX const

MCL3 'PK' or CEX2C 'PK') > * - VUD block > */ > -static struct CPRBX static_cprbx = { > +static const struct CPRBX static_cprbx = { > .cprb_len = 0x00DC, > .cprb_ver_id= 0x02, > .func_id= {0x54, 0x32}, Applied. Will be available with the next merge. Thanks and have a nice day. Harald Freudenberger

Re: [PATCH v1] crypto: caam - set hwrng quality level

true entropy in RNG's bitstream * (per mill). */ ... quality = estimation of true entropy per mill. I understand this as quality=1000 meaning 100% entropy. However, the core code currently does not really check this value. When more than one hwrng sources do register, simple the one with the higher quality value wins :-) The value is not even checked to be in a given range. I searched through some device drivers which do register at the hwrng and it looks like most of the drivers do not even set this value. My feeling is, you should use 999 when your hardware provides 'perfect' random. So there is a chance for an even 'more perfect' hardware coming up later to overrule your 'perfect' hardware. regards Harald Freudenberger

Re: [PATCH v1] crypto: caam - set hwrng quality level

* (per mill). */ ... quality = estimation of true entropy per mill. I understand this as quality=1000 meaning 100% entropy. However, the core code currently does not really check this value. When more than one hwrng sources do register, simple the one with the higher quality value wins :-) The value is not even checked to be in a given range. I searched through some device drivers which do register at the hwrng and it looks like most of the drivers do not even set this value. My feeling is, you should use 999 when your hardware provides 'perfect' random. So there is a chance for an even 'more perfect' hardware coming up later to overrule your 'perfect' hardware. regards Harald Freudenberger

Re: [PATCH] s390: crypto make ap_bus explicitly non-modular

On 02/13/2017 01:03 PM, Harald Freudenberger wrote: > On 02/09/2017 03:48 PM, Paul Gortmaker wrote: >> The Makefile in drivers/s390 has: >> >> obj-y += cio/ block/ char/ crypto/ net/ scsi/ virtio/ >> >> ..and the Makefile in crypto/ has: >> >>

Re: [PATCH] s390: crypto make ap_bus explicitly non-modular

On 02/13/2017 01:03 PM, Harald Freudenberger wrote: > On 02/09/2017 03:48 PM, Paul Gortmaker wrote: >> The Makefile in drivers/s390 has: >> >> obj-y += cio/ block/ char/ crypto/ net/ scsi/ virtio/ >> >> ..and the Makefile in crypto/ has: >> >>

Re: [PATCH] s390: crypto make ap_bus explicitly non-modular

h since the file does declare > some module parameters even though it is not modular itself. > > Cc: Harald Freudenberger <fre...@de.ibm.com> > Cc: Martin Schwidefsky <schwidef...@de.ibm.com> > Cc: Heiko Carstens <heiko.carst...@de.ibm.com> > Cc: linux-s...@vger.kernel.or

Re: [PATCH] s390: crypto make ap_bus explicitly non-modular

h since the file does declare > some module parameters even though it is not modular itself. > > Cc: Harald Freudenberger > Cc: Martin Schwidefsky > Cc: Heiko Carstens > Cc: linux-s...@vger.kernel.org > Signed-off-by: Paul Gortmaker > --- > drivers/s390/crypto/ap_bus.