On Fri, 24 Jan 2020 15:54:54 +0100 Eric Farman <farman@xxxxxxxxxxxxx> 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(-) >
