From: Cornelia Huck <cohuck@redhat.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: Farhan Ali <alifm@linux.ibm.com>,
Halil Pasic <pasic@linux.ibm.com>,
Pierre Morel <pmorel@linux.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 7/7] s390/cio: Remove vfio-ccw checks of command codes
Date: Mon, 6 May 2019 18:18:50 +0200 [thread overview]
Message-ID: <20190506181850.4b1b8300.cohuck@redhat.com> (raw)
In-Reply-To: <65313674-09be-88c0-4b5e-c99527f26532@linux.ibm.com>
On Mon, 6 May 2019 11:46:59 -0400
Eric Farman <farman@linux.ibm.com> wrote:
> On 5/6/19 11:37 AM, Cornelia Huck wrote:
> > On Fri, 3 May 2019 15:49:12 +0200
> > Eric Farman <farman@linux.ibm.com> wrote:
> >
> >> If the CCW being processed is a No-Operation, then by definition no
> >> data is being transferred. Let's fold those checks into the normal
> >> CCW processors, rather than skipping out early.
> >>
> >> Likewise, if the CCW being processed is a "test" (an invented
> >> definition to simply mean it ends in a zero),
> >
> > The "Common I/O Device Commands" document actually defines this :)
>
> Blech, okay so I didn't look early enough in that document. Section 1.5
> it is. :)
>
> >
> >> let's permit that to go
> >> through to the hardware. There's nothing inherently unique about
> >> those command codes versus one that ends in an eight [1], or any other
> >> otherwise valid command codes that are undefined for the device type
> >> in question.
> >
> > But I agree that everything possible should be sent to the hardware.
> >
> >>
> >> [1] POPS states that a x08 is a TIC CCW, and that having any high-order
> >> bits enabled is invalid for format-1 CCWs. For format-0 CCWs, the
> >> high-order bits are ignored.
> >>
> >> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> >> ---
> >> drivers/s390/cio/vfio_ccw_cp.c | 11 +++++------
> >> 1 file changed, 5 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
> >> index 36d76b821209..c0a52025bf06 100644
> >> --- a/drivers/s390/cio/vfio_ccw_cp.c
> >> +++ b/drivers/s390/cio/vfio_ccw_cp.c
> >> @@ -289,8 +289,6 @@ static long copy_ccw_from_iova(struct channel_program *cp,
> >> #define ccw_is_read_backward(_ccw) (((_ccw)->cmd_code & 0x0F) == 0x0C)
> >> #define ccw_is_sense(_ccw) (((_ccw)->cmd_code & 0x0F) == CCW_CMD_BASIC_SENSE)
> >>
> >> -#define ccw_is_test(_ccw) (((_ccw)->cmd_code & 0x0F) == 0)
> >> -
> >> #define ccw_is_noop(_ccw) ((_ccw)->cmd_code == CCW_CMD_NOOP)
> >>
> >> #define ccw_is_tic(_ccw) ((_ccw)->cmd_code == CCW_CMD_TIC)
> >> @@ -314,6 +312,10 @@ static inline int ccw_does_data_transfer(struct ccw1 *ccw)
> >> if (ccw->count == 0)
> >> return 0;
> >>
> >> + /* If the command is a NOP, then no data will be transferred */
> >> + if (ccw_is_noop(ccw))
> >> + return 0;
> >> +
> >
> > Don't you need to return 0 here for any test command as well?
> >
> > (If I read the doc correctly, we'll just get a unit check in any case,
> > as there are no parallel I/O interfaces on modern s390 boxes. Even if
> > we had a parallel I/O interface, we'd just collect the status, and not
> > get any data transfer. FWIW, the QEMU ccw interpreter for emulated
> > devices rejects test ccws with a channel program check, which looks
> > wrong; should be a command reject instead.)
>
> I will go back and look. I thought when I sent a test command with an
> address that wasn't translated I got an unhappy result, which is why I
> ripped this check out.
Ugh, I just looked at the current PoP and that specifies ccws[1] of test
type as 'invalid' (generating a channel program check). So, the current
PoP and the (old) I/O device commands seem to disagree :/ Do you know
if there's any update to the latter? I think I'll just leave QEMU as it
is, as that at least agrees with the current PoP...
>
> I was trying to use test CCWs as a safety valve for Halil's Status
> Modifier concern, so maybe I had something else wrong on that pile.
> (The careful observer would note that that code was not included here. :)
:)
>
> >
> >> /* If the skip flag is off, then data will be transferred */
> >> if (!ccw_is_skip(ccw))
> >> return 1;
> >> @@ -398,7 +400,7 @@ static void ccwchain_cda_free(struct ccwchain *chain, int idx)
> >> {
> >> struct ccw1 *ccw = chain->ch_ccw + idx;
> >>
> >> - if (ccw_is_test(ccw) || ccw_is_noop(ccw) || ccw_is_tic(ccw))
> >> + if (ccw_is_tic(ccw))
> >> return;
> >>
> >> kfree((void *)(u64)ccw->cda);
> >> @@ -723,9 +725,6 @@ static int ccwchain_fetch_one(struct ccwchain *chain,
> >> {
> >> struct ccw1 *ccw = chain->ch_ccw + idx;
> >>
> >> - if (ccw_is_test(ccw) || ccw_is_noop(ccw))
> >> - return 0;
> >> -
> >> if (ccw_is_tic(ccw))
> >> return ccwchain_fetch_tic(chain, idx, cp);
> >>
> >
[1] tcws are a bit different; but we don't support them anyway.
next prev parent reply other threads:[~2019-05-06 16:18 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-03 13:49 [PATCH v1 0/7] s390: vfio-ccw fixes Eric Farman
2019-05-03 13:49 ` [PATCH 1/7] s390/cio: Update SCSW if it points to the end of the chain Eric Farman
2019-05-06 14:47 ` Cornelia Huck
2019-05-06 15:23 ` Eric Farman
2019-05-03 13:49 ` [PATCH 2/7] s390/cio: Set vfio-ccw FSM state before ioeventfd Eric Farman
2019-05-06 14:51 ` Cornelia Huck
2019-05-06 16:36 ` Eric Farman
2019-05-07 8:32 ` Pierre Morel
2019-05-03 13:49 ` [PATCH 3/7] s390/cio: Split pfn_array_alloc_pin into pieces Eric Farman
2019-05-08 10:43 ` Cornelia Huck
2019-05-08 13:25 ` Eric Farman
2019-05-08 13:36 ` Cornelia Huck
2019-05-03 13:49 ` [PATCH 4/7] s390/cio: Initialize the host addresses in pfn_array Eric Farman
2019-05-03 13:49 ` [PATCH 5/7] s390/cio: Allow zero-length CCWs in vfio-ccw Eric Farman
2019-05-03 13:49 ` [PATCH 6/7] s390/cio: Don't pin vfio pages for empty transfers Eric Farman
2019-05-06 15:20 ` Cornelia Huck
2019-05-06 15:40 ` Eric Farman
2019-05-03 13:49 ` [PATCH 7/7] s390/cio: Remove vfio-ccw checks of command codes Eric Farman
2019-05-06 12:56 ` Pierre Morel
2019-05-06 15:39 ` Eric Farman
2019-05-06 20:47 ` Eric Farman
2019-05-07 8:52 ` Pierre Morel
2019-05-07 16:43 ` Eric Farman
2019-05-08 9:22 ` Pierre Morel
2019-05-08 10:06 ` Cornelia Huck
2019-05-08 19:38 ` Eric Farman
2019-05-10 11:47 ` Cornelia Huck
2019-05-10 14:24 ` Eric Farman
2019-05-14 14:29 ` Cornelia Huck
2019-05-14 18:29 ` Eric Farman
2019-05-06 15:37 ` Cornelia Huck
2019-05-06 15:46 ` Eric Farman
2019-05-06 16:18 ` Cornelia Huck [this message]
2019-05-06 16:25 ` Eric Farman
2019-05-06 16:31 ` 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=20190506181850.4b1b8300.cohuck@redhat.com \
--to=cohuck@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 \
/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.