From: Cornelia Huck <cohuck@redhat.com>
To: Pierre Morel <pmorel@linux.ibm.com>
Cc: borntraeger@de.ibm.com, alex.williamson@redhat.com,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
kvm@vger.kernel.org, frankja@linux.ibm.com,
akrowiak@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 v3 4/9] s390: ap: tools to find a queue with a specific APQN
Date: Fri, 15 Feb 2019 10:49:04 +0100 [thread overview]
Message-ID: <20190215104904.5cbe31bb.cohuck@redhat.com> (raw)
In-Reply-To: <1550152269-6317-5-git-send-email-pmorel@linux.ibm.com>
On Thu, 14 Feb 2019 14:51:04 +0100
Pierre Morel <pmorel@linux.ibm.com> wrote:
> We need to find the queue with a specific APQN during the
> handling of the interception of the PQAP/AQIC instruction.
>
> To handle the AP associated device reference count we keep
> track of it in the vfio_ap_queue until we put the device.
So, the relationship is
(struct ap_device)--(driver_data)-->(struct vfio_ap_queue)--(pointer)-->(struct ap_device)
? IOW, a backlink?
If so, can't you already set that up during probe?
Or am I confused by the various similar devices again? Maybe a diagram
would help...
>
> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 54 +++++++++++++++++++++++++++++++++++
> drivers/s390/crypto/vfio_ap_private.h | 1 +
> 2 files changed, 55 insertions(+)
>
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 900b9cf..2a52c9b 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -24,6 +24,60 @@
> #define VFIO_AP_MDEV_TYPE_HWVIRT "passthrough"
> #define VFIO_AP_MDEV_NAME_HWVIRT "VFIO AP Passthrough Device"
>
> +/**
> + * vfio_ap_check_apqn: check if a ap_queue is of a given APQN
> + *
> + * Returns 1 if we have a match.
> + * Otherwise returns 0.
> + */
> +static int vfio_ap_check_apqn(struct device *dev, void *data)
> +{
> + struct vfio_ap_queue *q = dev_get_drvdata(dev);
> +
> + return (q->apqn == *(int *)data);
> +}
> +
> +/**
> + * vfio_ap_get_queue: Retrieve a queue with a specific APQN
> + * @apqn: The queue APQN
> + *
> + * Retrieve a queue with a specific APQN from the list of the
> + * devices associated to the vfio_ap_driver.
> + *
> + * The vfio_ap_queue has been already associated with the device
> + * during the probe.
> + * Store the associated device for reference counting
> + *
> + * Returns the pointer to the associated vfio_ap_queue
> + */
> +static __attribute__((unused))
Eww. Can you get rid of that by reordering or squashing patches?
> + struct vfio_ap_queue *vfio_ap_get_queue(int apqn)
> +{
> + struct device *dev;
> + struct vfio_ap_queue *q;
> +
> + dev = driver_find_device(&matrix_dev->vfio_ap_drv->driver, NULL, &apqn,
> + vfio_ap_check_apqn);
> + if (!dev)
> + return NULL;
> + q = dev_get_drvdata(dev);
> + q->dev = dev;
> + return q;
> +}
> +
> +/**
> + * vfio_ap_put_queue: lower device reference count for a queue
> + * @q: The queue
> + *
> + * put the associated device
> + *
> + */
> +static __attribute__((unused)) void vfio_ap_put_queue(struct vfio_ap_queue *q)
> +{
> + put_device(q->dev);
> + q->dev = NULL;
> +}
> +
> static void vfio_ap_matrix_init(struct ap_config_info *info,
> struct ap_matrix *matrix)
> {
> diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
> index 8836f01..081f0d7 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -87,6 +87,7 @@ extern int vfio_ap_mdev_register(void);
> extern void vfio_ap_mdev_unregister(void);
>
> struct vfio_ap_queue {
> + struct device *dev;
> int apqn;
> };
> #endif /* _VFIO_AP_PRIVATE_H_ */
next prev parent reply other threads:[~2019-02-15 9:49 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 13:51 [PATCH v3 0/9] [RFC] vfio: ap: ioctl definitions for AP Queue Interrupt Control Pierre Morel
2019-02-14 13:51 ` [PATCH v3 1/9] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem Pierre Morel
2019-02-14 14:54 ` Cornelia Huck
2019-02-14 15:05 ` Christian Borntraeger
2019-02-14 15:40 ` Cornelia Huck
2019-02-14 17:12 ` Tony Krowiak
2019-02-14 17:35 ` Pierre Morel
2019-02-14 15:47 ` Pierre Morel
2019-02-14 16:57 ` Cornelia Huck
2019-02-14 17:36 ` Pierre Morel
2019-02-14 18:30 ` Tony Krowiak
2019-02-15 9:11 ` Cornelia Huck
2019-02-15 21:59 ` Tony Krowiak
2019-02-18 12:01 ` Cornelia Huck
2019-02-18 16:35 ` Tony Krowiak
2019-02-18 16:57 ` Cornelia Huck
2019-02-19 22:27 ` Tony Krowiak
2019-02-20 9:05 ` Cornelia Huck
2019-02-14 15:01 ` Christian Borntraeger
2019-02-14 15:09 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 2/9] s390: ap: kvm: setting a hook for PQAP instructions Pierre Morel
2019-02-14 15:54 ` Cornelia Huck
2019-02-14 16:45 ` Pierre Morel
2019-02-15 9:26 ` Cornelia Huck
2019-02-15 9:55 ` Pierre Morel
2019-02-15 22:02 ` Tony Krowiak
2019-02-18 18:29 ` Pierre Morel
2019-02-18 22:42 ` Cornelia Huck
2019-02-19 19:50 ` Pierre Morel
2019-02-19 22:36 ` Tony Krowiak
2019-02-21 12:40 ` Pierre Morel
2019-02-19 22:50 ` Tony Krowiak
2019-02-14 13:51 ` [PATCH v3 3/9] s390: ap: new vfio_ap_queue structure Pierre Morel
2019-02-15 9:37 ` Cornelia Huck
2019-02-15 9:58 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 4/9] s390: ap: tools to find a queue with a specific APQN Pierre Morel
2019-02-15 9:49 ` Cornelia Huck [this message]
2019-02-15 10:10 ` Pierre Morel
2019-02-15 10:24 ` Cornelia Huck
2019-02-15 22:13 ` Tony Krowiak
2019-02-18 12:21 ` Cornelia Huck
2019-02-18 18:32 ` Pierre Morel
2019-02-22 15:04 ` Tony Krowiak
2019-02-14 13:51 ` [PATCH v3 5/9] s390: ap: tools to associate a queue to a matrix Pierre Morel
2019-02-15 22:30 ` Tony Krowiak
2019-02-18 18:36 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 6/9] vfio: ap: register IOMMU VFIO notifier Pierre Morel
2019-02-15 22:55 ` Tony Krowiak
2019-02-19 9:59 ` Halil Pasic
2019-02-19 19:04 ` Pierre Morel
2019-02-19 21:33 ` Tony Krowiak
2019-02-19 18:51 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 7/9] s390: ap: implement PAPQ AQIC interception in kernel Pierre Morel
2019-02-15 23:11 ` Tony Krowiak
2019-02-19 19:16 ` Pierre Morel
2019-02-20 11:54 ` Halil Pasic
2019-02-21 12:50 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 8/9] s390: ap: Cleanup on removing the AP device Pierre Morel
2019-02-15 23:29 ` Tony Krowiak
2019-02-19 19:29 ` Pierre Morel
2019-02-15 23:36 ` Tony Krowiak
2019-02-19 19:41 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 9/9] s390: ap: kvm: add AP Queue Interruption Control facility Pierre Morel
2019-02-14 20:33 ` [PATCH v3 0/9] [RFC] vfio: ap: ioctl definitions for AP Queue Interrupt Control Tony Krowiak
2019-02-15 8:44 ` 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=20190215104904.5cbe31bb.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.