From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
Liu Yi L <yi.l.liu@intel.com>, Halil Pasic <pasic@linux.ibm.com>,
kvm@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v1 02/18] vfio/ccw: Fix FSM state if mdev probe fails
Date: Fri, 3 Jun 2022 09:21:23 -0400 [thread overview]
Message-ID: <65e84b02-6cd3-a230-f1e0-d22e2e70024d@linux.ibm.com> (raw)
In-Reply-To: <20220602171948.2790690-3-farman@linux.ibm.com>
On 6/2/22 1:19 PM, Eric Farman wrote:
> The FSM is in STANDBY state when arriving in vfio_ccw_mdev_probe(),
> and this routine converts it to IDLE as part of its processing.
> The error exit sets it to IDLE (again) but clears the private->mdev
> pointer.
>
> The FSM should of course be managing the state itself, but the
> correct thing for vfio_ccw_mdev_probe() to do would be to put
> the state back the way it found it.
>
> The corresponding check of private->mdev in vfio_ccw_sch_io_todo()
> can be removed, since the distinction is unnecessary at this point.
>
> Fixes: 3bf1311f351ef ("vfio/ccw: Convert to use vfio_register_emulated_iommu_dev()")
> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> ---
> drivers/s390/cio/vfio_ccw_drv.c | 2 +-
> drivers/s390/cio/vfio_ccw_ops.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
> index 35055eb94115..b18b4582bc8b 100644
> --- a/drivers/s390/cio/vfio_ccw_drv.c
> +++ b/drivers/s390/cio/vfio_ccw_drv.c
> @@ -108,7 +108,7 @@ static void vfio_ccw_sch_io_todo(struct work_struct *work)
> * has finished. Do not overwrite a possible processing
> * state if the final interrupt was for HSCH or CSCH.
> */
> - if (private->mdev && cp_is_finished)
> + if (cp_is_finished)
> private->state = VFIO_CCW_STATE_IDLE;
Took me a bit to convince myself this was OK, mainly because AFAICT
despite the change below the fsm jumptable would still allow you to
reach this code when in STANDBY. But, it should only be possible for an
unsolicited interrupt (e.g. unsolicited implies !cp_is_finished) so we
would still avoid a STANDBY->IDLE transition on accident.
Maybe work unsolicited interrupt into the comment block above along with
HSCH/CSCH?
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
>
> if (private->io_trigger)
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
> index bebae21228aa..a403d059a4e6 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -146,7 +146,7 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
> vfio_uninit_group_dev(&private->vdev);
> atomic_inc(&private->avail);
> private->mdev = NULL;
> - private->state = VFIO_CCW_STATE_IDLE;
> + private->state = VFIO_CCW_STATE_STANDBY;
next prev parent reply other threads:[~2022-06-03 13:21 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-02 17:19 [PATCH v1 00/18] VFIO ccw/mdev rework Eric Farman
2022-06-02 17:19 ` [PATCH v1 01/18] vfio/ccw: Remove UUID from s390 debug log Eric Farman
2022-06-02 18:55 ` Jason Gunthorpe
2022-06-02 19:51 ` Matthew Rosato
2022-06-03 19:03 ` Eric Farman
2022-06-06 20:45 ` Matthew Rosato
2022-06-02 17:19 ` [PATCH v1 02/18] vfio/ccw: Fix FSM state if mdev probe fails Eric Farman
2022-06-02 18:58 ` Jason Gunthorpe
2022-06-03 13:21 ` Matthew Rosato [this message]
2022-06-03 19:12 ` Eric Farman
2022-06-06 20:44 ` Matthew Rosato
2022-06-02 17:19 ` [PATCH v1 03/18] vfio/ccw: Ensure mdev->dev is cleared on mdev remove Eric Farman
2022-06-03 13:25 ` Matthew Rosato
2022-06-03 13:37 ` Jason Gunthorpe
2022-06-03 15:20 ` Tony Krowiak
2022-06-02 17:19 ` [PATCH v1 04/18] vfio/ccw: Do not change FSM state in subchannel event Eric Farman
2022-06-02 17:19 ` [PATCH v1 05/18] vfio/ccw: Remove private->mdev Eric Farman
2022-06-02 19:02 ` Jason Gunthorpe
2022-06-02 19:13 ` Eric Farman
2022-06-02 17:19 ` [PATCH v1 06/18] vfio/ccw: Pass enum to FSM event jumptable Eric Farman
2022-06-02 19:02 ` Jason Gunthorpe
2022-06-02 19:22 ` Matthew Rosato
2022-06-02 17:19 ` [PATCH v1 07/18] vfio/ccw: Flatten MDEV device (un)register Eric Farman
2022-06-02 19:03 ` Jason Gunthorpe
2022-06-02 19:14 ` Matthew Rosato
2022-06-03 20:38 ` Eric Farman
2022-06-02 17:19 ` [PATCH v1 08/18] vfio/ccw: Check that private pointer is not NULL Eric Farman
2022-06-02 19:04 ` Matthew Rosato
2022-06-02 19:05 ` Jason Gunthorpe
2022-06-02 17:19 ` [PATCH v1 09/18] vfio/ccw: Create an OPEN FSM Event Eric Farman
2022-06-02 19:08 ` Jason Gunthorpe
2022-06-02 17:19 ` [PATCH v1 10/18] vfio/ccw: Create a CLOSE FSM event Eric Farman
2022-06-02 19:10 ` Jason Gunthorpe
2022-06-02 17:19 ` [PATCH v1 11/18] vfio/ccw: Refactor vfio_ccw_mdev_reset Eric Farman
2022-06-02 19:11 ` Jason Gunthorpe
2022-06-02 17:19 ` [PATCH v1 12/18] vfio/ccw: Move FSM open/close to MDEV open/close Eric Farman
2022-06-02 19:14 ` Jason Gunthorpe
2022-06-02 17:19 ` [PATCH v1 13/18] vfio/mdev: Consolidate all the device_api sysfs into the core code Eric Farman
2022-06-03 6:36 ` Christoph Hellwig
2022-06-03 14:55 ` Tony Krowiak
2022-06-06 19:43 ` Kirti Wankhede
2022-06-10 7:22 ` Tian, Kevin
2022-06-02 17:19 ` [PATCH v1 14/18] vfio/mdev: Add mdev available instance checking to the core Eric Farman
2022-06-03 15:02 ` Tony Krowiak
2022-06-06 20:02 ` Kirti Wankhede
2022-06-06 20:23 ` Eric Farman
2022-06-06 20:37 ` Matthew Rosato
2022-06-10 7:43 ` Tian, Kevin
2022-06-13 6:46 ` Christoph Hellwig
2022-06-13 14:08 ` Eric Farman
2022-06-02 17:19 ` [PATCH v1 15/18] vfio/ccw: Manage private with mdev Eric Farman
2022-06-02 17:19 ` [PATCH v1 16/18] vfio/ccw: Create a get_private routine Eric Farman
2022-06-02 19:17 ` Jason Gunthorpe
2022-06-02 17:19 ` [PATCH v1 17/18] vfio: Export vfio_device_try_get() Eric Farman
2022-06-03 7:46 ` Cornelia Huck
2022-06-02 17:19 ` [PATCH v1 18/18] vfio/ccw: Manage ccw/mdev reference counts Eric Farman
2022-06-02 19:20 ` Jason Gunthorpe
2022-06-02 19:29 ` [PATCH v1 00/18] VFIO ccw/mdev rework Jason Gunthorpe
2022-06-10 4:11 ` Yi Liu
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=65e84b02-6cd3-a230-f1e0-d22e2e70024d@linux.ibm.com \
--to=mjrosato@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=farman@linux.ibm.com \
--cc=jgg@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.ibm.com \
--cc=yi.l.liu@intel.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