All of lore.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 J . Herne" <jjherne@linux.ibm.com>,
	Jared Rossi <jrossi@linux.ibm.com>,
	linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v1 0/1] vfio-ccw: Fix interrupt handling for HALT/CLEAR
Date: Fri, 24 Jan 2020 16:28:04 +0100	[thread overview]
Message-ID: <20200124162804.1a32e22a.cohuck@redhat.com> (raw)
In-Reply-To: <20200124145455.51181-1-farman@linux.ibm.com>

On Fri, 24 Jan 2020 15:54:54 +0100
Eric Farman <farman@linux.ibm.com> wrote:

> Conny,
> 
> As I mentioned offline, I have been encountering some problems while
> testing the channel path code.  By pure coincidence, I found some
> really good clues that led me to this proposed fix.  I moved this
> commit to the head of my channel path v2 code, but think maybe it
> should be sent by itself so it doesn't get lost in that noise.
> 
> Figure 16-6 in SA22-7832-12 (POPS) goes into great detail of the
> contents of the irb.cpa based on the other bits in the IRB.
> Both the existing code and this new patch treates the irb.cpa as
> valid all the time, even though that table has many many entries
> where the cpa contents are "unpredictable."  Methinks that this
> is partially how we got into this mess, so maybe I need to write
> some smarter logic here anyway?  Thoughts?

Yes, we probably should go over this table a bit. I think the generic
common I/O layer code has some checks where it does exactly that, but
these are probably only done on the ccw_device level (i.e. in the
normal I/O subchannel driver). Maybe we can refactor/reuse some of
those checks?

> 
> (Disclaimer1:  I didn't go back and re-read the conversations
> that were had for the commit I marked in the "Fixes:" tag,
> but will just to make sure we didn't miss something.)
> 
> (Disclaimer2:  This makes my torturing-of-the-chpids test run
> quite nicely, but I didn't go back to try some of the other
> cruel-and-unusual tests at my disposable to ensure this patch
> doesn't cause any other regressions.  That's on today's agenda.)
> 
> Eric Farman (1):
>   vfio-ccw: Don't free channel programs for unrelated interrupts
> 
>  drivers/s390/cio/vfio_ccw_cp.c  | 11 +++++++++--
>  drivers/s390/cio/vfio_ccw_cp.h  |  2 +-
>  drivers/s390/cio/vfio_ccw_drv.c |  4 ++--
>  3 files changed, 12 insertions(+), 5 deletions(-)
> 

      parent reply	other threads:[~2020-01-24 15:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24 14:54 [PATCH v1 0/1] vfio-ccw: Fix interrupt handling for HALT/CLEAR Eric Farman
2020-01-24 14:54 ` [PATCH v1 1/1] vfio-ccw: Don't free channel programs for unrelated interrupts Eric Farman
2020-01-24 15:33   ` Cornelia Huck
2020-01-24 16:08     ` Eric Farman
2020-01-27 12:52       ` Cornelia Huck
2020-01-27 21:28         ` Eric Farman
2020-01-28  9:58           ` Cornelia Huck
2020-01-28 14:42             ` Eric Farman
2020-01-29  4:13               ` Eric Farman
2020-01-29 12:00                 ` Cornelia Huck
2020-01-29 16:48                   ` Eric Farman
2020-01-24 15:28 ` Cornelia Huck [this message]

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=20200124162804.1a32e22a.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 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.