kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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 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).