public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Krowiak <akrowiak@linux.ibm.com>
To: Pierre Morel <pmorel@linux.ibm.com>, borntraeger@de.ibm.com
Cc: alex.williamson@redhat.com, cohuck@redhat.com,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	kvm@vger.kernel.org, frankja@linux.ibm.com, pasic@linux.ibm.com,
	david@redhat.com, schwidefsky@de.ibm.com,
	heiko.carstens@de.ibm.com, freude@linux.ibm.com,
	mimu@linux.ibm.com
Subject: Re: [PATCH v6 1/7] s390: ap: kvm: add PQAP interception for AQIC
Date: Thu, 28 Mar 2019 12:12:10 -0400	[thread overview]
Message-ID: <32716ed4-559f-0c36-cdf3-4c6662e02f4b@linux.ibm.com> (raw)
In-Reply-To: <1553265828-27823-2-git-send-email-pmorel@linux.ibm.com>

On 3/22/19 10:43 AM, Pierre Morel wrote:
> We prepare the interception of the PQAP/AQIC instruction for
> the case the AQIC facility is enabled in the guest.
> 
> First of all we do not want to change existing behavior when
> intercepting AP instructions without the SIE allowing the guest
> to use AP instructions.
> 
> In this patch we only handle the AQIC interception allowed by
> facility 65 which will be enabled when the complete interception
> infrastructure will be present.
> 
> We add a callback inside the KVM arch structure for s390 for
> a VFIO driver to handle a specific response to the PQAP
> instruction with the AQIC command and only this command.
> 
> But we want to be able to return a correct answer to the guest
> even there is no VFIO AP driver in the kernel.
> Therefor, we inject the correct exceptions from inside KVM for the
> case the callback is not initialized, which happens when the vfio_ap
> driver is not loaded.
> 
> We do consider the responsability of the driver to always initialize
> the PQAP callback if it defines queues by initializing the CRYCB for
> a guest.
> If the callback has been setup we call it.
> If not we setup an answer considering that no queue is available
> for the guest when no callback has been setup.
> 
> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> ---
>   arch/s390/include/asm/kvm_host.h      |  8 ++++
>   arch/s390/kvm/priv.c                  | 90 +++++++++++++++++++++++++++++++++++
>   drivers/s390/crypto/vfio_ap_private.h |  2 +
>   3 files changed, 100 insertions(+)
> 
> diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
> index a496276..624460b 100644
> --- a/arch/s390/include/asm/kvm_host.h
> +++ b/arch/s390/include/asm/kvm_host.h
> @@ -18,6 +18,7 @@
>   #include <linux/kvm_host.h>
>   #include <linux/kvm.h>
>   #include <linux/seqlock.h>
> +#include <linux/module.h>
>   #include <asm/debug.h>
>   #include <asm/cpu.h>
>   #include <asm/fpu/api.h>
> @@ -721,8 +722,15 @@ struct kvm_s390_cpu_model {
>   	unsigned short ibc;
>   };
>   
> +struct kvm_s390_module_hook {
> +	int (*hook)(struct kvm_vcpu *vcpu);
> +	void *data;
> +	struct module *owner;
> +};
> +
>   struct kvm_s390_crypto {
>   	struct kvm_s390_crypto_cb *crycb;
> +	struct kvm_s390_module_hook *pqap_hook;
>   	__u32 crycbd;
>   	__u8 aes_kw;
>   	__u8 dea_kw;
> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
> index 8679bd7..793e48a 100644
> --- a/arch/s390/kvm/priv.c
> +++ b/arch/s390/kvm/priv.c
> @@ -27,6 +27,7 @@
>   #include <asm/io.h>
>   #include <asm/ptrace.h>
>   #include <asm/sclp.h>
> +#include <asm/ap.h>
>   #include "gaccess.h"
>   #include "kvm-s390.h"
>   #include "trace.h"
> @@ -592,6 +593,93 @@ static int handle_io_inst(struct kvm_vcpu *vcpu)
>   	}
>   }
>   
> +/*
> + * handle_pqap: Handling pqap interception
> + * @vcpu: the vcpu having issue the pqap instruction
> + *
> + * We now support PQAP/AQIC instructions and we need to correctly
> + * answer the guest even if no dedicated driver's hook is available.
> + *
> + * The intercepting code calls a dedicated callback for this instruction
> + * if a driver did register one in the CRYPTO satellite of the
> + * SIE block.
> + *
> + * For PQAP AQIC and TAPQ instructions, verify privilege and specifications.
> + *
> + * If no callback available, the queues are not available, return this to
> + * the caller.
> + * Else return the value returned by the callback.
> + */
> +static int handle_pqap(struct kvm_vcpu *vcpu)
> +{
> +	struct ap_queue_status status = {};
> +	unsigned long reg0;
> +	int ret;
> +	uint8_t fc;
> +
> +	/* Verify that the AP instruction are available */
> +	if (!ap_instructions_available())
> +		return -EOPNOTSUPP;
> +	/* Verify that the guest is allowed to use AP instructions */
> +	if (!(vcpu->arch.sie_block->eca & ECA_APIE))
> +		return -EOPNOTSUPP;
> +	/*
> +	 * The only possibly intercepted instructions when AP instructions are
> +	 * available for the guest are AQIC and TAPQ with the t bit set
> +	 * since we do not set IC.3 (FIII) we currently will not intercept
> +	 * TAPQ.
> +	 * The following code will only treat AQIC function code.
> +	 */
> +	reg0 = vcpu->run->s.regs.gprs[0];
> +	fc = reg0 >> 24;
> +	if (fc != 0x03) {
> +		pr_warn("%s: Unexpected interception code 0x%02x\n",
> +			__func__, fc);
> +		return -EOPNOTSUPP;
> +	}
> +	/* All PQAP instructions are allowed for guest kernel only */
> +	if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE)
> +		return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP);
> +	/*
> +	 * Common tests for PQAP instructions to generate a specification
> +	 * exception
> +	 */
> +	/* Zero bits overwrite produce a specification exception */
> +	if (reg0 & 0x007f0000UL)
> +		goto specification_except;
> +	/* If APXA is not installed APQN is limited */
> +	if (!(vcpu->kvm->arch.crypto.crycbd & 0x02))
> +		if (reg0 & 0x000030f0UL)
> +			goto specification_except;
> +	/* AQIC needs facility 65 */
> +	if (!test_kvm_facility(vcpu->kvm, 65))
> +		goto specification_except;
> +
> +	/*
> +	 * Verify that the hook callback is registered, lock the owner
> +	 * and call the hook.
> +	 */
> +	if (vcpu->kvm->arch.crypto.pqap_hook) {
> +		if (!try_module_get(vcpu->kvm->arch.crypto.pqap_hook->owner))
> +			return -EOPNOTSUPP;
> +		ret = vcpu->kvm->arch.crypto.pqap_hook->hook(vcpu);
> +		module_put(vcpu->kvm->arch.crypto.pqap_hook->owner);
> +		return ret;
> +	}
> +	/*
> +	 * It is the duty of the vfio_driver to register a hook
> +	 * If it does not and we get an exception on AQIC we must
> +	 * guess that there is no vfio_ap_driver at all and no one
> +	 * to handle the guests's CRYCB and the CRYCB is empty.
> +	 */
> +	status.response_code = 0x01;
> +	memcpy(&vcpu->run->s.regs.gprs[1], &status, sizeof(status));
> +	return 0;
> +
> +specification_except:
> +	return kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION);
> +}
> +
>   static int handle_stfl(struct kvm_vcpu *vcpu)
>   {
>   	int rc;
> @@ -878,6 +966,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 <linux/mdev.h>
>   #include <linux/delay.h>
>   #include <linux/mutex.h>
> +#include <linux/kvm_host.h>
>   
>   #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;

I don't understand the purpose of adding this field. We set up the
the kvm->arch.crypto.pqap_hook in the vfio_ap_mdev_set_kvm which is
also in this same file, why not just use a static struct 
kvm_s390_module_hook and reuse it when setting up
kvm->arch.crypto.pqap_hook? It saves you from initializing it every
time an ap_matrix_mdev is created.

>   };
>   
>   extern int vfio_ap_mdev_register(void);
> 

  parent reply	other threads:[~2019-03-28 16:12 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22 14:43 [PATCH v6 0/7] vfio: ap: AP Queue Interrupt Control Pierre Morel
2019-03-22 14:43 ` [PATCH v6 1/7] s390: ap: kvm: add PQAP interception for AQIC Pierre Morel
2019-03-26 18:57   ` Tony Krowiak
2019-03-27 16:06     ` Tony Krowiak
2019-03-28 12:43     ` Pierre Morel
2019-03-28 15:24       ` Tony Krowiak
2019-03-28 16:12   ` Tony Krowiak [this message]
2019-03-29  8:52     ` Pierre Morel
2019-03-29 13:02       ` Tony Krowiak
2019-03-22 14:43 ` [PATCH v6 2/7] s390: ap: new vfio_ap_queue structure Pierre Morel
2019-03-25  8:05   ` Harald Freudenberger
2019-03-28 13:12     ` Pierre Morel
2019-03-26 20:45   ` Tony Krowiak
2019-03-27 11:00     ` Harald Freudenberger
2019-03-28 12:53       ` Pierre Morel
2019-03-28 13:06     ` Pierre Morel
2019-03-28 15:32       ` Tony Krowiak
2019-03-28 16:06         ` Pierre Morel
2019-04-02 12:47   ` Pierre Morel
2019-03-22 14:43 ` [PATCH v6 3/7] s390: ap: setup relation betwen KVM and mediated device Pierre Morel
2019-03-28 16:12   ` Tony Krowiak
2019-03-28 16:27     ` Pierre Morel
2019-03-28 17:25       ` Tony Krowiak
2019-03-29  8:58         ` Pierre Morel
2019-03-29 13:06           ` Tony Krowiak
2019-03-22 14:43 ` [PATCH v6 4/7] vfio: ap: register IOMMU VFIO notifier Pierre Morel
2019-03-28 20:46   ` Tony Krowiak
2019-03-29  9:31     ` Pierre Morel
2019-03-29 13:14       ` Tony Krowiak
2019-03-22 14:43 ` [PATCH v6 5/7] s390: ap: implement PAPQ AQIC interception in kernel Pierre Morel
2019-03-22 14:43 ` [PATCH v6 6/7] s390: ap: Cleanup on removing the AP device Pierre Morel
2019-03-22 14:43 ` [PATCH v6 7/7] s390: ap: kvm: Enable PQAP/AQIC facility for the guest Pierre Morel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32716ed4-559f-0c36-cdf3-4c6662e02f4b@linux.ibm.com \
    --to=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mimu@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=pmorel@linux.ibm.com \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox