From: Cornelia Huck <cohuck@redhat.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH RFC 1/1] vfio-ccw: add some logging
Date: Fri, 23 Aug 2019 12:44:56 +0200 [thread overview]
Message-ID: <20190823124456.5230ed70.cohuck@redhat.com> (raw)
In-Reply-To: <81414605-c676-6e7e-4ee8-8dbfe7ae0a76@linux.ibm.com>
On Wed, 21 Aug 2019 11:54:26 -0400
Eric Farman <farman@linux.ibm.com> wrote:
> On 8/16/19 11:15 AM, Cornelia Huck wrote:
> > Usually, the common I/O layer logs various things into the s390
> > cio debug feature, which has been very helpful in the past when
> > looking at crash dumps. As vfio-ccw devices unbind from the
> > standard I/O subchannel driver, we lose some information there.
> >
> > Let's introduce some vfio-ccw debug features and log some things
> > there. (Unfortunately we cannot reuse the cio debug feature from
> > a module.)
>
> Boo :(
Yeah, that would have been even more useful :(
>
> >
> > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> > ---
> > drivers/s390/cio/vfio_ccw_drv.c | 50 ++++++++++++++++++++++++++--
> > drivers/s390/cio/vfio_ccw_fsm.c | 51 ++++++++++++++++++++++++++++-
> > drivers/s390/cio/vfio_ccw_ops.c | 10 ++++++
> > drivers/s390/cio/vfio_ccw_private.h | 17 ++++++++++
> > 4 files changed, 124 insertions(+), 4 deletions(-)
> >
>
> ...snip...
>
> > diff --git a/drivers/s390/cio/vfio_ccw_fsm.c b/drivers/s390/cio/vfio_ccw_fsm.c
> > index 49d9d3da0282..4a1e727c62d9 100644
> > --- a/drivers/s390/cio/vfio_ccw_fsm.c
> > +++ b/drivers/s390/cio/vfio_ccw_fsm.c
>
> ...snip...
>
> > @@ -239,18 +258,32 @@ static void fsm_io_request(struct vfio_ccw_private *private,
> > /* Don't try to build a cp if transport mode is specified. */
> > if (orb->tm.b) {
> > io_region->ret_code = -EOPNOTSUPP;
> > + VFIO_CCW_MSG_EVENT(2,
> > + "%pUl (%x.%x.%04x): transport mode\n",
> > + mdev_uuid(mdev), schid.cssid,
> > + schid.ssid, schid.sch_no);
> > errstr = "transport mode";
> > goto err_out;
> > }
> > io_region->ret_code = cp_init(&private->cp, mdev_dev(mdev),
> > orb);
> > if (io_region->ret_code) {
> > + VFIO_CCW_MSG_EVENT(2,
> > + "%pUl (%x.%x.%04x): cp_init=%d\n",
> > + mdev_uuid(mdev), schid.cssid,
> > + schid.ssid, schid.sch_no,
> > + io_region->ret_code);
> > errstr = "cp init";
> > goto err_out;
> > }
> >
> > io_region->ret_code = cp_prefetch(&private->cp);
> > if (io_region->ret_code) {
> > + VFIO_CCW_MSG_EVENT(2,
> > + "%pUl (%x.%x.%04x): cp_prefetch=%d\n",
> > + mdev_uuid(mdev), schid.cssid,
> > + schid.ssid, schid.sch_no,
> > + io_region->ret_code);
> > errstr = "cp prefetch";
> > cp_free(&private->cp);
> > goto err_out;
> > @@ -259,23 +292,36 @@ static void fsm_io_request(struct vfio_ccw_private *private,
> > /* Start channel program and wait for I/O interrupt. */
> > io_region->ret_code = fsm_io_helper(private);
> > if (io_region->ret_code) {
> > + VFIO_CCW_MSG_EVENT(2,
> > + "%pUl (%x.%x.%04x): fsm_io_helper=%d\n",
> > + mdev_uuid(mdev), schid.cssid,
> > + schid.ssid, schid.sch_no,
> > + io_region->ret_code);
>
> I suppose these ones could be squashed into err_out, and use errstr as
> substitution for the message text. But this is fine.
>
> > errstr = "cp fsm_io_helper";
> > cp_free(&private->cp);
> > goto err_out;
> > }
> > return;
> > } else if (scsw->cmd.fctl & SCSW_FCTL_HALT_FUNC) {
> > + VFIO_CCW_MSG_EVENT(2,
> > + "%pUl (%x.%x.%04x): halt on io_region\n",
> > + mdev_uuid(mdev), schid.cssid,
> > + schid.ssid, schid.sch_no);
> > /* halt is handled via the async cmd region */
> > io_region->ret_code = -EOPNOTSUPP;
> > goto err_out;
> > } else if (scsw->cmd.fctl & SCSW_FCTL_CLEAR_FUNC) {
> > + VFIO_CCW_MSG_EVENT(2,
> > + "%pUl (%x.%x.%04x): clear on io_region\n",
> > + mdev_uuid(mdev), schid.cssid,
> > + schid.ssid, schid.sch_no);
>
> The above idea would need errstr to be set to something other than
> "request" here, which maybe isn't a bad thing anyway. :)
The trace event tries to cover all of the different error cases in one
go, so it is not quite optimal (but still useful). For the sprintf
event, I tried to include better error-specific information (also, I'm
probably a bit paranoid with regard to strings in the sprintf view :)
We could probably enhance the trace event here, and we should evaluate
adding more of them, as they and the dbf complement each other.
>
> > /* clear is handled via the async cmd region */
> > io_region->ret_code = -EOPNOTSUPP;
> > goto err_out;
> > }
> >
> > err_out:
> > - trace_vfio_ccw_io_fctl(scsw->cmd.fctl, get_schid(private),
> > + trace_vfio_ccw_io_fctl(scsw->cmd.fctl, schid,
> > io_region->ret_code, errstr);
> > }
> >
(...)
> This all looks pretty standard compared to the existing cio stuff, and
> would be a good addition for vfio-ccw.
I pretty much copied some of the basic stuff over. We can always add
more later :)
>
> Reviewed-by: Eric Farman <farman@linux.ibm.com>
>
Thanks!
I'll go ahead and queue this for the next release, unless someone
objects.
next prev parent reply other threads:[~2019-08-23 10:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-16 15:15 [PATCH RFC 0/1] s390dbf logging for vfio-ccw Cornelia Huck
2019-08-16 15:15 ` [PATCH RFC 1/1] vfio-ccw: add some logging Cornelia Huck
2019-08-21 15:54 ` Eric Farman
2019-08-23 10:44 ` Cornelia Huck [this message]
2019-08-23 11:48 ` 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=20190823124456.5230ed70.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=farman@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