linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pierre Morel <pmorel@linux.ibm.com>
To: Matthew Rosato <mjrosato@linux.ibm.com>, linux-s390@vger.kernel.org
Cc: alex.williamson@redhat.com, cohuck@redhat.com,
	schnelle@linux.ibm.com, farman@linux.ibm.com,
	borntraeger@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
	gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
	frankja@linux.ibm.com, david@redhat.com, imbrenda@linux.ibm.com,
	vneethv@linux.ibm.com, oberpar@linux.ibm.com,
	freude@linux.ibm.com, thuth@redhat.com, pasic@linux.ibm.com,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 19/30] KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding
Date: Tue, 25 Jan 2022 13:41:35 +0100	[thread overview]
Message-ID: <bb8f5da2-19d2-bf94-a2b4-f5b6f0f91995@linux.ibm.com> (raw)
In-Reply-To: <20220114203145.242984-20-mjrosato@linux.ibm.com>



On 1/14/22 21:31, Matthew Rosato wrote:
> These routines will be wired into the vfio_pci_zdev ioctl handlers to
> respond to requests to enable / disable a device for Adapter Event
> Notifications / Adapter Interuption Forwarding.
> 
> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
> ---
>   arch/s390/include/asm/kvm_pci.h |   7 ++
>   arch/s390/kvm/pci.c             | 203 ++++++++++++++++++++++++++++++++
>   arch/s390/pci/pci_insn.c        |   1 +
>   3 files changed, 211 insertions(+)
> 
> diff --git a/arch/s390/include/asm/kvm_pci.h b/arch/s390/include/asm/kvm_pci.h
> index 072401aa7922..01fe14fffd7a 100644
> --- a/arch/s390/include/asm/kvm_pci.h
> +++ b/arch/s390/include/asm/kvm_pci.h
> @@ -16,16 +16,23 @@
>   #include <linux/kvm_host.h>
>   #include <linux/kvm.h>
>   #include <linux/pci.h>
> +#include <asm/pci_insn.h>
>   
>   struct kvm_zdev {
>   	struct zpci_dev *zdev;
>   	struct kvm *kvm;
> +	struct zpci_fib fib;
>   };
>   
>   int kvm_s390_pci_dev_open(struct zpci_dev *zdev);
>   void kvm_s390_pci_dev_release(struct zpci_dev *zdev);
>   void kvm_s390_pci_attach_kvm(struct zpci_dev *zdev, struct kvm *kvm);
>   
> +int kvm_s390_pci_aif_probe(struct zpci_dev *zdev);
> +int kvm_s390_pci_aif_enable(struct zpci_dev *zdev, struct zpci_fib *fib,
> +			    bool assist);
> +int kvm_s390_pci_aif_disable(struct zpci_dev *zdev);
> +
>   int kvm_s390_pci_interp_probe(struct zpci_dev *zdev);
>   int kvm_s390_pci_interp_enable(struct zpci_dev *zdev);
>   int kvm_s390_pci_interp_disable(struct zpci_dev *zdev);
> diff --git a/arch/s390/kvm/pci.c b/arch/s390/kvm/pci.c
> index 122d0992b521..7ed9abc476b6 100644
> --- a/arch/s390/kvm/pci.c
> +++ b/arch/s390/kvm/pci.c
> @@ -12,6 +12,7 @@
>   #include <asm/kvm_pci.h>
>   #include <asm/pci.h>
>   #include <asm/pci_insn.h>
> +#include <asm/pci_io.h>
>   #include <asm/sclp.h>
>   #include "pci.h"
>   #include "kvm-s390.h"
> @@ -145,6 +146,204 @@ int kvm_s390_pci_aen_init(u8 nisc)
>   	return rc;
>   }
>   
> +/* Modify PCI: Register floating adapter interruption forwarding */
> +static int kvm_zpci_set_airq(struct zpci_dev *zdev)
> +{
> +	u64 req = ZPCI_CREATE_REQ(zdev->fh, 0, ZPCI_MOD_FC_REG_INT);
> +	struct zpci_fib fib = {0};

I prefer {} instead of {0} even it does the same it looks wrong to me.

> +	u8 status;
> +
> +	fib.fmt0.isc = zdev->kzdev->fib.fmt0.isc;
> +	fib.fmt0.sum = 1;       /* enable summary notifications */
> +	fib.fmt0.noi = airq_iv_end(zdev->aibv);
> +	fib.fmt0.aibv = virt_to_phys(zdev->aibv->vector);
> +	fib.fmt0.aibvo = 0;
> +	fib.fmt0.aisb = virt_to_phys(aift->sbv->vector + (zdev->aisb / 64) * 8);
> +	fib.fmt0.aisbo = zdev->aisb & 63;
> +	fib.gd = zdev->gd;
> +
> +	return zpci_mod_fc(req, &fib, &status) ? -EIO : 0;
> +}
> +
> +/* Modify PCI: Unregister floating adapter interruption forwarding */
> +static int kvm_zpci_clear_airq(struct zpci_dev *zdev)
> +{
> +	u64 req = ZPCI_CREATE_REQ(zdev->fh, 0, ZPCI_MOD_FC_DEREG_INT);
> +	struct zpci_fib fib = {0};

same here

> +	u8 cc, status;
> +
> +	fib.gd = zdev->gd;
> +
> +	cc = zpci_mod_fc(req, &fib, &status);
> +	if (cc == 3 || (cc == 1 && status == 24))
> +		/* Function already gone or IRQs already deregistered. */
> +		cc = 0;
> +
> +	return cc ? -EIO : 0;
> +}
> +
> +int kvm_s390_pci_aif_probe(struct zpci_dev *zdev)
> +{
> +	/* Must have appropriate hardware facilities */
> +	if (!(sclp.has_aeni && test_facility(71)))
> +		return -EINVAL;
> +
> +	/* Must have a KVM association registered */
> +	if (!zdev->kzdev || !zdev->kzdev->kvm)
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(kvm_s390_pci_aif_probe);
> +
> +int kvm_s390_pci_aif_enable(struct zpci_dev *zdev, struct zpci_fib *fib,
> +			    bool assist)
> +{
> +	struct page *aibv_page, *aisb_page = NULL;
> +	unsigned int msi_vecs, idx;
> +	struct zpci_gaite *gaite;
> +	unsigned long bit;
> +	struct kvm *kvm;
> +	phys_addr_t gaddr;
> +	int rc = 0;
> +
> +	/*
> +	 * Interrupt forwarding is only applicable if the device is already
> +	 * enabled for interpretation
> +	 */
> +	if (zdev->gd == 0)
> +		return -EINVAL;
> +
> +	kvm = zdev->kzdev->kvm;
> +	msi_vecs = min_t(unsigned int, fib->fmt0.noi, zdev->max_msi);
> +
> +	/* Replace AIBV address */
> +	idx = srcu_read_lock(&kvm->srcu);
> +	aibv_page = gfn_to_page(kvm, gpa_to_gfn((gpa_t)fib->fmt0.aibv));
> +	srcu_read_unlock(&kvm->srcu, idx);
> +	if (is_error_page(aibv_page)) {
> +		rc = -EIO;
> +		goto out;
> +	}
> +	gaddr = page_to_phys(aibv_page) + (fib->fmt0.aibv & ~PAGE_MASK);
> +	fib->fmt0.aibv = gaddr;
> +
> +	/* Pin the guest AISB if one was specified */
> +	if (fib->fmt0.sum == 1) {
> +		idx = srcu_read_lock(&kvm->srcu);
> +		aisb_page = gfn_to_page(kvm, gpa_to_gfn((gpa_t)fib->fmt0.aisb));
> +		srcu_read_unlock(&kvm->srcu, idx);
> +		if (is_error_page(aisb_page)) {
> +			rc = -EIO;
> +			goto unpin1;
> +		}
> +	}
> +
> +	/* AISB must be allocated before we can fill in GAITE */
> +	mutex_lock(&aift->lock);
> +	bit = airq_iv_alloc_bit(aift->sbv);
> +	if (bit == -1UL)
> +		goto unpin2;
> +	zdev->aisb = bit;

aisb here is the aisb offset right?
Then may be add a comment as in gait and fmt0 aisb is an address.

> +	zdev->aibv = airq_iv_create(msi_vecs, AIRQ_IV_DATA |
> +					      AIRQ_IV_BITLOCK |
> +					      AIRQ_IV_GUESTVEC,
> +				    (unsigned long *)fib->fmt0.aibv);

phys_to_virt ?

> +
> +	spin_lock_irq(&aift->gait_lock);
> +	gaite = (struct zpci_gaite *)aift->gait + (zdev->aisb *
> +						   sizeof(struct zpci_gaite));
> +
> +	/* If assist not requested, host will get all alerts */
> +	if (assist)
> +		gaite->gisa = (u32)(u64)&kvm->arch.sie_page2->gisa;

virt_to_phys ?

> +	else
> +		gaite->gisa = 0;
> +
> +	gaite->gisc = fib->fmt0.isc;
> +	gaite->count++;
> +	gaite->aisbo = fib->fmt0.aisbo;
> +	gaite->aisb = virt_to_phys(page_address(aisb_page) + (fib->fmt0.aisb &
> +							      ~PAGE_MASK));
> +	aift->kzdev[zdev->aisb] = zdev->kzdev;
> +	spin_unlock_irq(&aift->gait_lock);
> +
> +	/* Update guest FIB for re-issue */
> +	fib->fmt0.aisbo = zdev->aisb & 63;
> +	fib->fmt0.aisb = virt_to_phys(aift->sbv->vector + (zdev->aisb / 64) * 8);
> +	fib->fmt0.isc = kvm_s390_gisc_register(kvm, gaite->gisc);
> +
> +	/* Save some guest fib values in the host for later use */
> +	zdev->kzdev->fib.fmt0.isc = fib->fmt0.isc;
> +	zdev->kzdev->fib.fmt0.aibv = fib->fmt0.aibv;
> +	mutex_unlock(&aift->lock);
> +
> +	/* Issue the clp to setup the irq now */
> +	rc = kvm_zpci_set_airq(zdev);
> +	return rc;
> +
> +unpin2:
> +	mutex_unlock(&aift->lock);
> +	if (fib->fmt0.sum == 1) {
> +		gaddr = page_to_phys(aisb_page);
> +		kvm_release_pfn_dirty(gaddr >> PAGE_SHIFT);
> +	}
> +unpin1:
> +	kvm_release_pfn_dirty(fib->fmt0.aibv >> PAGE_SHIFT);
> +out:
> +	return rc;
> +}
> +EXPORT_SYMBOL_GPL(kvm_s390_pci_aif_enable);
> +
> +int kvm_s390_pci_aif_disable(struct zpci_dev *zdev)
> +{
> +	struct kvm_zdev *kzdev = zdev->kzdev;
> +	struct zpci_gaite *gaite;
> +	int rc;
> +	u8 isc;
> +
> +	if (zdev->gd == 0)
> +		return -EINVAL;
> +
> +	/* Even if the clear fails due to an error, clear the GAITE */
> +	rc = kvm_zpci_clear_airq(zdev);

Having a look at kvm_zpci_clear_airq() the only possible error seems to 
be when an error recovery is in progress.
The error returned for a wrong FH, function does not exist anymore, or 
if the interrupt vectors are already deregistered by the instruction are 
returned as success by the function.

How can we be sure that we have no conflict with a recovery in progress?
Shouldn't we in this case let the recovery process handle the function 
and stop here?

Doesn't the aif lock mutex placed after and not before the clear_irq 
open a door for race condition with the recovery?

> +
> +	mutex_lock(&aift->lock);
> +	if (zdev->kzdev->fib.fmt0.aibv == 0)
> +		goto out;
> +	spin_lock_irq(&aift->gait_lock);
> +	gaite = (struct zpci_gaite *)aift->gait + (zdev->aisb *
> +						   sizeof(struct zpci_gaite));
> +	isc = gaite->gisc;
> +	gaite->count--;
> +	if (gaite->count == 0) {
> +		/* Release guest AIBV and AISB */
> +		kvm_release_pfn_dirty(kzdev->fib.fmt0.aibv >> PAGE_SHIFT);
> +		if (gaite->aisb != 0)
> +			kvm_release_pfn_dirty(gaite->aisb >> PAGE_SHIFT);
> +		/* Clear the GAIT entry */
> +		gaite->aisb = 0;
> +		gaite->gisc = 0;
> +		gaite->aisbo = 0;
> +		gaite->gisa = 0;
> +		aift->kzdev[zdev->aisb] = 0;
> +		/* Clear zdev info */
> +		airq_iv_free_bit(aift->sbv, zdev->aisb);
> +		airq_iv_release(zdev->aibv);
> +		zdev->aisb = 0;
> +		zdev->aibv = NULL;
> +	}
> +	spin_unlock_irq(&aift->gait_lock);
> +	kvm_s390_gisc_unregister(kzdev->kvm, isc);

Don't we need to check the return value?
And maybe to report it to the caller?

> +	kzdev->fib.fmt0.isc = 0;
> +	kzdev->fib.fmt0.aibv = 0;
> +out:
> +	mutex_unlock(&aift->lock);
> +
> +	return rc;
> +}
> +EXPORT_SYMBOL_GPL(kvm_s390_pci_aif_disable);
> +
>   int kvm_s390_pci_interp_probe(struct zpci_dev *zdev)
>   {
>   	/* Must have appropriate hardware facilities */
> @@ -221,6 +420,10 @@ int kvm_s390_pci_interp_disable(struct zpci_dev *zdev)
>   	if (zdev->gd == 0)
>   		return -EINVAL;
>   
> +	/* Forwarding must be turned off before interpretation */
> +	if (zdev->kzdev->fib.fmt0.aibv != 0)
> +		kvm_s390_pci_aif_disable(zdev);
> +
>   	/* Remove the host CLP guest designation */
>   	zdev->gd = 0;
>   
> diff --git a/arch/s390/pci/pci_insn.c b/arch/s390/pci/pci_insn.c
> index ca6399d52767..f7d0e29bbf0b 100644
> --- a/arch/s390/pci/pci_insn.c
> +++ b/arch/s390/pci/pci_insn.c
> @@ -59,6 +59,7 @@ u8 zpci_mod_fc(u64 req, struct zpci_fib *fib, u8 *status)
>   
>   	return cc;
>   }
> +EXPORT_SYMBOL_GPL(zpci_mod_fc);
>   
>   /* Refresh PCI Translations */
>   static inline u8 __rpcit(u64 fn, u64 addr, u64 range, u8 *status)
> 

-- 
Pierre Morel
IBM Lab Boeblingen

  reply	other threads:[~2022-01-25 12:43 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14 20:31 [PATCH v2 00/30] KVM: s390: enable zPCI for interpretive execution Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 01/30] s390/sclp: detect the zPCI load/store interpretation facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 02/30] s390/sclp: detect the AISII facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 03/30] s390/sclp: detect the AENI facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 04/30] s390/sclp: detect the AISI facility Matthew Rosato
2022-01-17  7:57   ` Thomas Huth
2022-01-14 20:31 ` [PATCH v2 05/30] s390/airq: pass more TPI info to airq handlers Matthew Rosato
2022-01-17  8:27   ` Thomas Huth
2022-01-14 20:31 ` [PATCH v2 06/30] s390/airq: allow for airq structure that uses an input vector Matthew Rosato
2022-01-17 12:29   ` Claudio Imbrenda
2022-01-18 18:52     ` Matthew Rosato
2022-01-18  9:50   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 07/30] s390/pci: externalize the SIC operation controls and routine Matthew Rosato
2022-01-17 16:19   ` Niklas Schnelle
2022-01-26 10:07   ` Claudio Imbrenda
2022-01-27  9:57   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 08/30] s390/pci: stash associated GISA designation Matthew Rosato
2022-01-24 14:08   ` Pierre Morel
2022-01-24 15:12     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 09/30] s390/pci: export some routines related to RPCIT processing Matthew Rosato
2022-01-18  9:51   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 10/30] s390/pci: stash dtsm and maxstbl Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 11/30] s390/pci: add helper function to find device by handle Matthew Rosato
2022-01-18  9:53   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 12/30] s390/pci: get SHM information from list pci Matthew Rosato
2022-01-18 10:36   ` Pierre Morel
2022-01-26 10:13     ` Claudio Imbrenda
2022-01-27 13:41       ` Pierre Morel
2022-01-27 15:14         ` Matthew Rosato
2022-01-27 10:29   ` Niklas Schnelle
2022-01-14 20:31 ` [PATCH v2 13/30] s390/pci: return status from zpci_refresh_trans Matthew Rosato
2022-01-19 18:13   ` Pierre Morel
2022-01-26 10:45   ` Claudio Imbrenda
2022-01-27 10:30   ` Niklas Schnelle
2022-01-14 20:31 ` [PATCH v2 14/30] KVM: s390: pci: add basic kvm_zdev structure Matthew Rosato
2022-01-17 16:25   ` Pierre Morel
2022-01-18 17:32     ` Pierre Morel
2022-01-18 18:39       ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 15/30] KVM: s390: pci: do initial setup for AEN interpretation Matthew Rosato
2022-01-19 18:06   ` Pierre Morel
2022-01-19 20:19     ` Matthew Rosato
2022-01-25 12:23   ` Pierre Morel
2022-01-25 14:57     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 16/30] KVM: s390: pci: enable host forwarding of Adapter Event Notifications Matthew Rosato
2022-01-17 17:38   ` Pierre Morel
2022-01-18 17:25     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 17/30] KVM: s390: mechanism to enable guest zPCI Interpretation Matthew Rosato
2022-01-24 14:24   ` Pierre Morel
2022-01-24 15:28     ` Matthew Rosato
2022-01-24 17:15       ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 18/30] KVM: s390: pci: provide routines for enabling/disabling interpretation Matthew Rosato
2022-01-24 14:36   ` Pierre Morel
2022-01-24 15:14     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 19/30] KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding Matthew Rosato
2022-01-25 12:41   ` Pierre Morel [this message]
2022-01-25 15:44     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 20/30] KVM: s390: pci: provide routines for enabling/disabling IOAT assist Matthew Rosato
2022-01-25 13:29   ` Pierre Morel
2022-01-25 14:47     ` Matthew Rosato
2022-01-26  8:30       ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 21/30] KVM: s390: pci: handle refresh of PCI translations Matthew Rosato
2022-01-19  9:29   ` Pierre Morel
2022-01-19 16:39     ` Matthew Rosato
2022-01-19 18:25       ` Pierre Morel
2022-01-19 20:02         ` Matthew Rosato
2022-01-20  9:47           ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 22/30] KVM: s390: intercept the rpcit instruction Matthew Rosato
2022-01-18 11:05   ` Pierre Morel
2022-01-18 17:27     ` Matthew Rosato
2022-01-18 17:54       ` Pierre Morel
2022-01-19 14:06   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 23/30] vfio/pci: re-introduce CONFIG_VFIO_PCI_ZDEV Matthew Rosato
2022-01-18 17:20   ` Pierre Morel
2022-01-18 17:32     ` Matthew Rosato
2022-01-18 17:45       ` Pierre Morel
2022-01-18 18:05         ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 24/30] vfio-pci/zdev: wire up group notifier Matthew Rosato
2022-01-18 17:34   ` Pierre Morel
2022-01-18 18:37     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 25/30] vfio-pci/zdev: wire up zPCI interpretive execution support Matthew Rosato
2022-01-25 13:01   ` Pierre Morel
2022-01-25 14:21     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 26/30] vfio-pci/zdev: wire up zPCI adapter interrupt forwarding support Matthew Rosato
2022-01-19 17:10   ` Pierre Morel
2022-01-19 17:20     ` Matthew Rosato
2022-01-25 12:36   ` Pierre Morel
2022-01-25 14:16     ` Matthew Rosato
2022-01-26  8:24       ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 27/30] vfio-pci/zdev: wire up zPCI IOAT assist support Matthew Rosato
2022-01-19 14:03   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 28/30] vfio-pci/zdev: add DTSM to clp group capability Matthew Rosato
2022-01-19 13:48   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 29/30] KVM: s390: introduce CPU feature for zPCI Interpretation Matthew Rosato
2022-01-19 13:39   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 30/30] MAINTAINERS: additional files related kvm s390 pci passthrough Matthew Rosato
2022-01-14 20:49 ` [PATCH v2 00/30] KVM: s390: enable zPCI for interpretive execution Matthew Rosato
2022-01-19 18:10 ` 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=bb8f5da2-19d2-bf94-a2b4-f5b6f0f91995@linux.ibm.com \
    --to=pmorel@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=oberpar@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=thuth@redhat.com \
    --cc=vneethv@linux.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;
as well as URLs for NNTP newsgroup(s).