public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
	Jason Herne <jjherne@linux.ibm.com>,
	Jared Rossi <jrossi@linux.ibm.com>,
	linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [RFC PATCH v2 5/9] vfio-ccw: Introduce a new CRW region
Date: Tue, 7 Apr 2020 08:30:35 +0200	[thread overview]
Message-ID: <20200407083035.09ca4dfc.cohuck@redhat.com> (raw)
In-Reply-To: <db43381a-6769-07f1-7d4d-9c6c680bde4e@linux.ibm.com>

On Mon, 6 Apr 2020 17:43:42 -0400
Eric Farman <farman@linux.ibm.com> wrote:

> (Ah, didn't see this come in earlier.)
> 
> On 4/6/20 9:40 AM, Cornelia Huck wrote:
> > On Thu,  6 Feb 2020 22:38:21 +0100
> > Eric Farman <farman@linux.ibm.com> wrote:
> >   
> >> From: Farhan Ali <alifm@linux.ibm.com>
> >>
> >> This region provides a mechanism to pass Channel Report Word(s)
> >> that affect vfio-ccw devices, and need to be passed to the guest
> >> for its awareness and/or processing.
> >>
> >> The base driver (see crw_collect_info()) provides space for two
> >> CRWs, as a subchannel event may have two CRWs chained together
> >> (one for the ssid, one for the subcahnnel).  All other CRWs will
> >> only occupy the first one.  Even though this support will also
> >> only utilize the first one, we'll provide space for two also.
> >>
> >> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
> >> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> >> ---
> >>
> >> Notes:
> >>     v1-v2:
> >>      - Add new region info to Documentation/s390/vfio-ccw.rst [CH]
> >>      - Add a block comment to struct ccw_crw_region [CH]
> >>     
> >>     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
> >>
> >>  Documentation/s390/vfio-ccw.rst     | 15 ++++++++
> >>  drivers/s390/cio/vfio_ccw_chp.c     | 56 +++++++++++++++++++++++++++++
> >>  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       |  9 +++++
> >>  7 files changed, 108 insertions(+)
> >>  
> > 
> > (...)
> >   
> >> diff --git a/drivers/s390/cio/vfio_ccw_chp.c b/drivers/s390/cio/vfio_ccw_chp.c
> >> index 826d08379fe3..8fde94552149 100644
> >> --- a/drivers/s390/cio/vfio_ccw_chp.c
> >> +++ b/drivers/s390/cio/vfio_ccw_chp.c
> >> @@ -73,3 +73,59 @@ 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;
> >> +
> >> +	if (list_empty(&private->crw))
> >> +		return 0;  
> 
> This is actually nonsense, because the list isn't introduced for a
> couple of patches.
> 
> >> +
> >> +	mutex_lock(&private->io_mutex);
> >> +	region = private->region[i].data;
> >> +
> >> +	if (copy_to_user(buf, (void *)region + pos, count))
> >> +		ret = -EFAULT;
> >> +	else
> >> +		ret = count;
> >> +
> >> +	mutex_unlock(&private->io_mutex);
> >> +	return ret;
> >> +}  
> > 
> > Would it make sense to clear out the crw after it has been read by
> > userspace?  
> 
> Yes, I fixed this up in my in-progress v3 last week.  Sorry to waste
> some time, I should have mentioned it when I changed my branch locally.
> 
> I changed the list_empty() check above to bail out if the region is
> already zero, which I guess is why the userspace check looks for both.
> But if we only look at the contents of the region, then checking both is
> unnecessary.  Just do the copy and be done with it.

Yes, that makes sense.

> 
> > 
> > In patch 7, you add a notification for a new crw via eventfd, but
> > nothing is preventing userspace from reading this even if not
> > triggered. I also don't see the region being updated there until a new
> > crw is posted.
> > 
> > Or am I missing something?
> >   
> 

  reply	other threads:[~2020-04-07  6:30 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 21:38 [RFC PATCH v2 0/9] s390x/vfio-ccw: Channel Path Handling Eric Farman
2020-02-06 21:38 ` [RFC PATCH v2 1/9] vfio-ccw: Introduce new helper functions to free/destroy regions Eric Farman
2020-02-06 21:38 ` [RFC PATCH v2 2/9] vfio-ccw: Register a chp_event callback for vfio-ccw Eric Farman
2020-02-14 12:11   ` Cornelia Huck
2020-02-14 16:35     ` Eric Farman
2020-03-24 15:58       ` Cornelia Huck
2020-03-26  2:09         ` Eric Farman
2020-03-26  6:47           ` Cornelia Huck
2020-03-26 11:54             ` Eric Farman
2020-02-06 21:38 ` [RFC PATCH v2 3/9] vfio-ccw: Refactor the unregister of the async regions Eric Farman
2020-02-06 21:38 ` [RFC PATCH v2 4/9] vfio-ccw: Introduce a new schib region Eric Farman
2020-02-14 12:32   ` Cornelia Huck
2020-02-14 14:29     ` Eric Farman
2020-02-06 21:38 ` [RFC PATCH v2 5/9] vfio-ccw: Introduce a new CRW region Eric Farman
2020-04-06 13:40   ` Cornelia Huck
2020-04-06 21:43     ` Eric Farman
2020-04-07  6:30       ` Cornelia Huck [this message]
2020-02-06 21:38 ` [RFC PATCH v2 6/9] vfio-ccw: Refactor IRQ handlers Eric Farman
2020-02-06 21:38 ` [RFC PATCH v2 7/9] vfio-ccw: Wire up the CRW irq and CRW region Eric Farman
2020-02-14 13:34   ` Cornelia Huck
2020-02-14 16:24     ` Eric Farman
2020-03-24 16:34       ` Cornelia Huck
2020-03-26 18:51         ` Eric Farman
2020-04-06 13:52   ` Cornelia Huck
2020-04-06 22:11     ` Eric Farman
2020-02-06 21:38 ` [RFC PATCH v2 8/9] vfio-ccw: Add trace for CRW event Eric Farman
2020-02-06 21:38 ` [RFC PATCH v2 9/9] vfio-ccw: Remove inline get_schid() routine Eric Farman
2020-02-14 13:27   ` Cornelia Huck
2020-02-14 14:27     ` Eric Farman
2020-02-07  9:12 ` [RFC PATCH v2 0/9] s390x/vfio-ccw: Channel Path Handling Cornelia Huck
2020-02-07 13:26   ` Eric Farman

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=20200407083035.09ca4dfc.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 \
    --cc=pasic@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