From: Cornelia Huck <cohuck@redhat.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
Jason Herne <jjherne@linux.ibm.com>,
Jared Rossi <jrossi@linux.ibm.com>
Subject: Re: [RFC PATCH v1 06/10] vfio-ccw: Introduce a new CRW region
Date: Tue, 19 Nov 2019 18:17:26 +0100 [thread overview]
Message-ID: <20191119181726.440dd30d.cohuck@redhat.com> (raw)
In-Reply-To: <20191115025620.19593-7-farman@linux.ibm.com>
On Fri, 15 Nov 2019 03:56:16 +0100
Eric Farman <farman@linux.ibm.com> wrote:
> From: Farhan Ali <alifm@linux.ibm.com>
>
> This region can be used by userspace to get channel report
> words from vfio-ccw driver.
I think this needs a bit more explanation; this is for channel report
words concerning vfio-ccw devices that are supposed to be relayed to
the guest, IIUC?
>
> We provide space for two CRWs, per the limit in the
> base driver (see crw_collect_info()).
That rationale seems a bit sketchy.
As far as I know, current systems provide at most two crws chained
together for an event (one for the ssid + one for the subchannel id in
case of a subchannel event, one crw for other events); and that's the
reason why we provide space for two crws (unless there's something
upcoming which would need three crws chained together?)
>
> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> ---
>
> Notes:
> v0->v1: [EF]
> - Clean up checkpatch (whitespace) errors
> - Add ret=-ENOMEM in error path for new region
> - Add io_mutex for region read (originally in last patch)
> - Change crw1/crw2 to crw0/crw1
> - Reorder cleanup of regions
>
> drivers/s390/cio/vfio_ccw_chp.c | 53 +++++++++++++++++++++++++++++
> drivers/s390/cio/vfio_ccw_drv.c | 20 +++++++++++
> drivers/s390/cio/vfio_ccw_ops.c | 4 +++
> drivers/s390/cio/vfio_ccw_private.h | 3 ++
> include/uapi/linux/vfio.h | 1 +
> include/uapi/linux/vfio_ccw.h | 5 +++
> 6 files changed, 86 insertions(+)
>
> diff --git a/drivers/s390/cio/vfio_ccw_chp.c b/drivers/s390/cio/vfio_ccw_chp.c
> index 826d08379fe3..d1e8bfef06be 100644
> --- a/drivers/s390/cio/vfio_ccw_chp.c
> +++ b/drivers/s390/cio/vfio_ccw_chp.c
> @@ -73,3 +73,56 @@ int vfio_ccw_register_schib_dev_regions(struct vfio_ccw_private *private)
> VFIO_REGION_INFO_FLAG_READ,
> private->schib_region);
> }
> +
> +static ssize_t vfio_ccw_crw_region_read(struct vfio_ccw_private *private,
> + char __user *buf, size_t count,
> + loff_t *ppos)
> +{
> + unsigned int i = VFIO_CCW_OFFSET_TO_INDEX(*ppos) - VFIO_CCW_NUM_REGIONS;
> + loff_t pos = *ppos & VFIO_CCW_OFFSET_MASK;
> + struct ccw_crw_region *region;
> + int ret;
> +
> + if (pos + count > sizeof(*region))
> + return -EINVAL;
> +
> + mutex_lock(&private->io_mutex);
> + region = private->region[i].data;
> +
> + if (copy_to_user(buf, (void *)region + pos, count))
> + ret = -EFAULT;
> + else
> + ret = count;
> +
Can userspace read the same crw(s) multiple times? How can it find out
if there's something new in there?
> + mutex_unlock(&private->io_mutex);
> + return ret;
> +}
> +
(...)
> diff --git a/include/uapi/linux/vfio_ccw.h b/include/uapi/linux/vfio_ccw.h
> index 7c0a834e5d7a..88b125aad279 100644
> --- a/include/uapi/linux/vfio_ccw.h
> +++ b/include/uapi/linux/vfio_ccw.h
> @@ -39,4 +39,9 @@ struct ccw_schib_region {
> __u8 schib_area[SCHIB_AREA_SIZE];
> } __packed;
>
I think this one wants an explaining comment as well.
> +struct ccw_crw_region {
> + __u32 crw0;
> + __u32 crw1;
> +} __packed;
> +
> #endif
next prev parent reply other threads:[~2019-11-19 17:17 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-15 2:56 [RFC PATCH v1 00/10] s390/vfio-ccw: Channel Path Handling Eric Farman
2019-11-15 2:56 ` [RFC PATCH v1 01/10] vfio-ccw: Introduce new helper functions to free/destroy regions Eric Farman
2019-11-19 12:33 ` Cornelia Huck
2019-11-15 2:56 ` [RFC PATCH v1 02/10] vfio-ccw: Register a chp_event callback for vfio-ccw Eric Farman
2019-11-19 12:48 ` Cornelia Huck
2019-11-19 15:45 ` Eric Farman
2019-11-15 2:56 ` [RFC PATCH v1 03/10] vfio-ccw: Use subchannel lpm in the orb Eric Farman
2019-11-19 13:00 ` Cornelia Huck
2019-11-19 15:16 ` Eric Farman
2019-11-19 15:38 ` Cornelia Huck
2019-11-19 18:58 ` Eric Farman
2019-11-15 2:56 ` [RFC PATCH v1 04/10] vfio-ccw: Refactor the unregister of the async regions Eric Farman
2019-11-19 16:21 ` Cornelia Huck
2019-11-15 2:56 ` [RFC PATCH v1 05/10] vfio-ccw: Introduce a new schib region Eric Farman
2019-11-19 16:52 ` Cornelia Huck
2019-11-20 16:49 ` Eric Farman
2019-11-15 2:56 ` [RFC PATCH v1 06/10] vfio-ccw: Introduce a new CRW region Eric Farman
2019-11-19 17:17 ` Cornelia Huck [this message]
2019-11-15 2:56 ` [RFC PATCH v1 07/10] vfio-ccw: Refactor IRQ handlers Eric Farman
2019-11-19 17:18 ` Cornelia Huck
2019-11-15 2:56 ` [RFC PATCH v1 08/10] vfio-ccw: Wire up the CRW irq and CRW region Eric Farman
2019-11-19 18:52 ` Cornelia Huck
2019-12-05 20:43 ` Eric Farman
2019-12-06 10:21 ` Cornelia Huck
2019-12-06 21:24 ` Eric Farman
2019-12-09 12:38 ` Cornelia Huck
2019-11-15 2:56 ` [RFC PATCH v1 09/10] vfio-ccw: Add trace for CRW event Eric Farman
2019-11-15 2:56 ` [RFC PATCH v1 10/10] vfio-ccw: Remove inline get_schid() routine Eric Farman
2019-11-15 11:15 ` [RFC PATCH v1 00/10] s390/vfio-ccw: Channel Path Handling Cornelia Huck
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=20191119181726.440dd30d.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=farman@linux.ibm.com \
--cc=jjherne@linux.ibm.com \
--cc=jrossi@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
/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.