From: Cornelia Huck <cohuck@redhat.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: linux-s390@vger.kernel.org,
Alex Williamson <alex.williamson@redhat.com>,
Pierre Morel <pmorel@linux.ibm.com>,
kvm@vger.kernel.org, Farhan Ali <alifm@linux.ibm.com>,
qemu-devel@nongnu.org, Halil Pasic <pasic@linux.ibm.com>,
qemu-s390x@nongnu.org
Subject: Re: [PATCH 3/3] vfio-ccw: add handling for asnyc channel instructions
Date: Tue, 18 Dec 2018 17:45:21 +0100 [thread overview]
Message-ID: <20181218174521.331bf7bc.cohuck@redhat.com> (raw)
In-Reply-To: <ca97f673-621d-77c8-ed54-da2cebcf4a7c@linux.ibm.com>
On Mon, 17 Dec 2018 16:54:31 -0500
Eric Farman <farman@linux.ibm.com> wrote:
> On 11/22/2018 11:54 AM, Cornelia Huck wrote:
> > Add a region to the vfio-ccw device that can be used to submit
> > asynchronous I/O instructions. ssch continues to be handled by the
> > existing I/O region; the new region handles hsch and csch.
> >
> > Interrupt status continues to be reported through the same channels
> > as for ssch.
> >
> > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> > ---
> > drivers/s390/cio/Makefile | 3 +-
> > drivers/s390/cio/vfio_ccw_async.c | 88 ++++++++++++++++
> > drivers/s390/cio/vfio_ccw_drv.c | 48 ++++++---
> > drivers/s390/cio/vfio_ccw_fsm.c | 158 +++++++++++++++++++++++++++-
> > drivers/s390/cio/vfio_ccw_ops.c | 13 ++-
> > drivers/s390/cio/vfio_ccw_private.h | 6 ++
> > include/uapi/linux/vfio.h | 4 +
> > include/uapi/linux/vfio_ccw.h | 12 +++
> > 8 files changed, 313 insertions(+), 19 deletions(-)
> > create mode 100644 drivers/s390/cio/vfio_ccw_async.c
> > diff --git a/drivers/s390/cio/vfio_ccw_async.c b/drivers/s390/cio/vfio_ccw_async.c
> > new file mode 100644
> > index 000000000000..8c7f51d17d70
> > --- /dev/null
> > +++ b/drivers/s390/cio/vfio_ccw_async.c
> > @@ -0,0 +1,88 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Async I/O region for vfio_ccw
> > + *
> > + * Copyright Red Hat, Inc. 2018
> > + *
> > + * Author(s): Cornelia Huck <cohuck@redhat.com>
> > + */
> > +
> > +#include <linux/vfio.h>
> > +#include <linux/mdev.h>
> > +
> > +#include "vfio_ccw_private.h"
> > +
> > +static size_t vfio_ccw_async_region_read(struct vfio_ccw_private *private,
>
> I think this should return ssize_t ? (same for _write, below)
Yes, ssize_t makes more sense. Changed.
(vfio_pci_regops also has size_t; should probably be changed as well.)
>
> > + 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_cmd_region *region;
> > +
> > + if (pos + count > sizeof(*region))
> > + return -EINVAL;
> > +
> > + region = private->region[i].data;
> > + if (copy_to_user(buf, (void *)region + pos, count))
> > + return -EFAULT;
> > +
> > + return count;
> > +
> > +}
> > +
> > +static size_t vfio_ccw_async_region_write(struct vfio_ccw_private *private,
> > + const 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_cmd_region *region;
> > +
> > + if (pos + count > sizeof(*region))
> > + return -EINVAL;
> > +
> > + if (private->state == VFIO_CCW_STATE_NOT_OPER ||
> > + private->state == VFIO_CCW_STATE_STANDBY)
> > + return -EACCES;
> > +
> > + region = private->region[i].data;
> > + if (copy_from_user((void *)region + pos, buf, count))
> > + return -EFAULT;
> > +
> > + switch (region->command) {
> > + case VFIO_CCW_ASYNC_CMD_HSCH:
> > + vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_HALT_REQ);
> > + break;
> > + case VFIO_CCW_ASYNC_CMD_CSCH:
> > + vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_CLEAR_REQ);
> > + break;
>
> I find myself wondering why we add separate VFIO_CCW_EVENT_x_REQ entries
> for HALT and CLEAR, rather than a single VFIO_CCW_EVENT_ASYNC_REQ and a
> switch on cmd_region->command within it to go to fsm_do_halt,
> fsm_do_clear, or whatever.
In the end, it probably does not matter much where we do the switch.
When I started writing this, I thought I would want to allow clear in
more states than halt; but that does not make much sense (best to let
the hardware sort it out; see also the other discussions around
concurrency.)
>
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + return region->ret_code ? region->ret_code : count;
> > +}
(...)
> > diff --git a/drivers/s390/cio/vfio_ccw_fsm.c b/drivers/s390/cio/vfio_ccw_fsm.c
> > index f94aa01f9c36..0caf77e8f377 100644
> > --- a/drivers/s390/cio/vfio_ccw_fsm.c
> > +++ b/drivers/s390/cio/vfio_ccw_fsm.c
> > @@ -102,6 +179,20 @@ static void fsm_io_busy(struct vfio_ccw_private *private,
> > private->io_region->ret_code = -EBUSY;
> > }
> >
> > +static void fsm_async_error(struct vfio_ccw_private *private,
> > + enum vfio_ccw_event event)
> > +{
> > + pr_err("vfio-ccw: FSM: halt/clear request from state:%d\n",
> > + private->state);
>
> Worth stating whether it's a Halt or Clear here, rather than leaving it
> ambiguous?
Not sure. Also not sure if we want to fold the events, as you suggested
above :)
This also reminds me that I need to rebase this: some details in the
handling will need to be different without the BOXED state.
next prev parent reply other threads:[~2018-12-18 16:45 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-22 16:54 [PATCH 0/3] vfio-ccw: support hsch/csch (kernel part) Cornelia Huck
2018-11-22 16:54 ` [PATCH 1/3] vfio-ccw: add capabilities chain Cornelia Huck
2018-11-23 12:28 ` Pierre Morel
2018-11-23 12:45 ` Cornelia Huck
2018-11-23 13:26 ` Pierre Morel
2018-11-27 19:04 ` Farhan Ali
2018-11-28 9:05 ` Cornelia Huck
2018-12-17 21:53 ` Eric Farman
2018-12-18 17:24 ` Cornelia Huck
2018-12-18 17:56 ` Eric Farman
2018-12-19 16:28 ` Alex Williamson
2018-12-21 11:12 ` Cornelia Huck
2018-11-22 16:54 ` [PATCH 2/3] s390/cio: export hsch to modules Cornelia Huck
2018-11-23 12:30 ` Pierre Morel
2018-11-22 16:54 ` [PATCH 3/3] vfio-ccw: add handling for asnyc channel instructions Cornelia Huck
2018-11-23 13:08 ` Pierre Morel
2018-11-26 9:47 ` Cornelia Huck
2018-11-27 19:09 ` Farhan Ali
2018-11-28 9:02 ` Cornelia Huck
2018-11-28 14:31 ` Farhan Ali
2018-11-28 14:52 ` Cornelia Huck
2018-11-28 15:00 ` Farhan Ali
2018-11-28 15:35 ` Cornelia Huck
2018-11-28 15:55 ` Farhan Ali
2019-01-18 13:53 ` Cornelia Huck
2018-11-27 19:57 ` Farhan Ali
2018-11-28 8:41 ` Cornelia Huck
2018-11-28 16:36 ` [qemu-s390x] " Halil Pasic
2018-11-29 16:52 ` Cornelia Huck
2018-11-29 17:24 ` Halil Pasic
2018-12-17 21:54 ` Eric Farman
2018-12-18 16:45 ` Cornelia Huck [this message]
2018-11-24 21:07 ` [qemu-s390x] [PATCH 0/3] vfio-ccw: support hsch/csch (kernel part) Halil Pasic
2018-11-26 9:26 ` Cornelia Huck
2018-11-26 18:57 ` Farhan Ali
2018-11-26 19:00 ` Cornelia Huck
2018-12-04 12:38 ` Halil Pasic
2018-12-04 13:11 ` Cornelia Huck
2018-12-04 15:02 ` Halil Pasic
2018-12-05 12:54 ` Cornelia Huck
2018-12-05 18:34 ` Farhan Ali
2018-12-06 14:39 ` Cornelia Huck
2018-12-06 15:26 ` Farhan Ali
2018-12-06 16:21 ` Cornelia Huck
2018-12-06 17:50 ` Farhan Ali
2018-12-07 9:34 ` Cornelia Huck
2018-12-06 18:47 ` Halil Pasic
2018-12-07 10:05 ` Cornelia Huck
2018-12-07 15:49 ` Halil Pasic
2018-12-07 16:54 ` Halil Pasic
2018-12-19 11:54 ` Cornelia Huck
2018-12-19 14:17 ` Halil Pasic
2018-12-21 11:23 ` Cornelia Huck
2018-12-21 12:42 ` Halil Pasic
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=20181218174521.331bf7bc.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=alifm@linux.ibm.com \
--cc=farman@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.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.