On 5/15/19 8:43 AM, Cornelia Huck wrote:
On Wed, 15 May 2019 01:42:48 +0200
Eric Farman <farman@xxxxxxxxxxxxx> 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.
[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@xxxxxxxxxxxxx>
---
drivers/s390/cio/vfio_ccw_cp.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
