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

[Pierre Morel]

On 30/01/2019 18:48, Tony Krowiak wrote:
> The current AP bus implementation periodically polls the AP configuration
> to detect changes. When the AP configuration is dynamically changed via the
> SE or an SCLP instruction, the changes will not be reflected to sysfs until
> the next time the AP configuration is polled. The CHSC architecture
> provides a Store Event Information (SEI)command to make notification of an
> AP configuration change. This patch introduces a handler to process
> notification from the CHSC SEI command BY immediately kickING off an AP bus
> scan.
>
> Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>
> Reviewed-by: Halil Pasic <pasic@xxxxxxxxxxxxx>
> ---
>   arch/s390/include/asm/ap.h   | 12 ++++++++++++
>   drivers/s390/cio/chsc.c      | 12 ++++++++++++
>   drivers/s390/cio/chsc.h      |  1 +
>   drivers/s390/crypto/ap_bus.c | 12 ++++++++++++
>   4 files changed, 37 insertions(+)
>
> diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
> index 1a6a7092d942..c778593d509f 100644
> --- a/arch/s390/include/asm/ap.h
> +++ b/arch/s390/include/asm/ap.h
> @@ -360,4 +360,16 @@ static inline struct ap_queue_status ap_dqap(ap_qid_t qid,
>   	return reg1;
>   }
>   
> +/*
> + * Interface to tell the AP bus code that a configuration
> + * change has happened. The bus code should at least do
> + * an ap bus resource rescan.
> + */
> +#if IS_ENABLED(CONFIG_ZCRYPT)
> +void ap_bus_cfg_chg(void);
> +#else
> +#error "no CONFIG_ZCRYPT"
> +static void ap_bus_cfg_chg(void){};
> +#endif
> +
>   #endif /* _ASM_S390_AP_H_ */
> diff --git a/drivers/s390/cio/chsc.c b/drivers/s390/cio/chsc.c
> index a0baee25134c..dccccc337078 100644
> --- a/drivers/s390/cio/chsc.c
> +++ b/drivers/s390/cio/chsc.c
> @@ -586,6 +586,15 @@ static void chsc_process_sei_scm_avail(struct chsc_sei_nt0_area *sei_area)
>   			      " failed (rc=%d).\n", ret);
>   }
>   
> +static void chsc_process_sei_ap_cfg_chg(struct chsc_sei_nt0_area *sei_area)
> +{
> +	CIO_CRW_EVENT(3, "chsc: ap config changed\n");
> +	if (sei_area->rs != 5)

Why just return if the rs code is 5?

The event content code concerns the AP configuration change.

Should the source of the reporting of this change hold us from 
rescanning the available AP?


Regards,
Pierre


> +		return;
> +
> +	ap_bus_cfg_chg();
> +}
> +
>   static void chsc_process_sei_nt2(struct chsc_sei_nt2_area *sei_area)
>   {
>   	switch (sei_area->cc) {
> @@ -612,6 +621,9 @@ static void chsc_process_sei_nt0(struct chsc_sei_nt0_area *sei_area)
>   	case 2: /* i/o resource accessibility */
>   		chsc_process_sei_res_acc(sei_area);
>   		break;
> +	case 3: /* ap config changed */
> +		chsc_process_sei_ap_cfg_chg(sei_area);
> +		break;
>   	case 7: /* channel-path-availability information */
>   		chsc_process_sei_chp_avail(sei_area);
>   		break;
> diff --git a/drivers/s390/cio/chsc.h b/drivers/s390/cio/chsc.h
> index 78aba8d94eec..5651066c46e3 100644
> --- a/drivers/s390/cio/chsc.h
> +++ b/drivers/s390/cio/chsc.h
> @@ -9,6 +9,7 @@
>   #include <asm/chsc.h>
>   #include <asm/schid.h>
>   #include <asm/qdio.h>
> +#include <asm/ap.h>
>   
>   #define CHSC_SDA_OC_MSS   0x2
>   
> diff --git a/drivers/s390/crypto/ap_bus.c b/drivers/s390/crypto/ap_bus.c
> index 48ea0004a56d..94f621783d6b 100644
> --- a/drivers/s390/crypto/ap_bus.c
> +++ b/drivers/s390/crypto/ap_bus.c
> @@ -35,6 +35,7 @@
>   #include <linux/mod_devicetable.h>
>   #include <linux/debugfs.h>
>   #include <linux/ctype.h>
> +#include <asm/crw.h>
>   
>   #include "ap_bus.h"
>   #include "ap_debug.h"
> @@ -860,6 +861,17 @@ void ap_bus_force_rescan(void)
>   EXPORT_SYMBOL(ap_bus_force_rescan);
>   
>   /*
> +* A config change has happened, Force an ap bus rescan.
> +*/
> +void ap_bus_cfg_chg(void)
> +{
> +	AP_DBF(DBF_INFO, "%s config change, forcing bus rescan\n", __func__);
> +
> +	ap_bus_force_rescan();
> +}
> +EXPORT_SYMBOL(ap_bus_cfg_chg);
> +
> +/*
>    * hex2bitmap() - parse hex mask string and set bitmap.
>    * Valid strings are "0x012345678" with at least one valid hex number.
>    * Rest of the bitmap to the right is padded with 0. No spaces allowed


--
Pierre Morel
Linux/KVM/QEMU in BÃblingen - Germany