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 v2 7/7] s390/cio: Remove vfio-ccw checks of command codes
Date: Wed, 15 May 2019 15:42:07 +0200 [thread overview]
Message-ID: <20190515154207.3a6f7968.cohuck@redhat.com> (raw)
In-Reply-To: <1f0e2084-2e3d-bc97-f8cf-a40f194d7288@linux.ibm.com>
On Wed, 15 May 2019 09:36:01 -0400
Eric Farman <farman@linux.ibm.com> wrote:
> On 5/15/19 8:43 AM, Cornelia Huck wrote:
> > On Wed, 15 May 2019 01:42:48 +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), 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.
> >
> > Hm... let's tweak that a bit? It's not that "test" is an invented
> > category; it's just that this has not been a valid command for
> > post-s/370 and therefore should not get any special treatment and just
> > be sent to the hardware?
>
> Agreed, I should've re-read that one before I sent it... How about:
>
> Likewise, if the CCW being processed is a "test" (a category defined
> here as an opcode that contains zero in the lowest four bits) then no
> special processing is necessary as far as vfio-ccw is concerned.
> These command codes have not been valid since the S/370 days, meaning
> they are invalid in the same way as one that ends in an eight [1] or
> an otherwise valid command code that is undefined for the device type
> in question. Considering that, let's just process "test" CCWs like
> any other CCW, and send everything to the hardware.
Sounds good to me!
>
> >
> >>
> >> [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(-)
> >
>
next prev parent reply other threads:[~2019-05-15 13:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 23:42 [PATCH v2 0/7] s390: vfio-ccw fixes Eric Farman
2019-05-14 23:42 ` [PATCH v2 1/7] s390/cio: Update SCSW if it points to the end of the chain Eric Farman
2019-05-15 14:30 ` Farhan Ali
2019-05-14 23:42 ` [PATCH v2 2/7] s390/cio: Set vfio-ccw FSM state before ioeventfd Eric Farman
2019-05-15 14:36 ` Farhan Ali
2019-05-14 23:42 ` [PATCH v2 3/7] s390/cio: Split pfn_array_alloc_pin into pieces Eric Farman
2019-05-15 16:04 ` Farhan Ali
2019-05-14 23:42 ` [PATCH v2 4/7] s390/cio: Initialize the host addresses in pfn_array Eric Farman
2019-05-15 16:25 ` Farhan Ali
2019-05-14 23:42 ` [PATCH v2 5/7] s390/cio: Allow zero-length CCWs in vfio-ccw Eric Farman
2019-05-15 12:23 ` Cornelia Huck
2019-05-15 15:04 ` Eric Farman
2019-05-15 20:08 ` Farhan Ali
2019-05-16 9:59 ` Cornelia Huck
2019-05-16 10:48 ` Eric Farman
2019-05-14 23:42 ` [PATCH v2 6/7] s390/cio: Don't pin vfio pages for empty transfers Eric Farman
2019-05-14 23:42 ` [PATCH v2 7/7] s390/cio: Remove vfio-ccw checks of command codes Eric Farman
2019-05-15 12:43 ` Cornelia Huck
2019-05-15 13:36 ` Eric Farman
2019-05-15 13:42 ` Cornelia Huck [this message]
2019-05-15 12:45 ` [PATCH v2 0/7] s390: vfio-ccw fixes Cornelia Huck
2019-05-15 13:21 ` Eric Farman
2019-05-16 11:44 ` 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=20190515154207.3a6f7968.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox