All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Pierre Morel <pmorel@linux.ibm.com>
Cc: Eric Farman <farman@linux.ibm.com>,
	Farhan Ali <alifm@linux.ibm.com>,
	Halil Pasic <pasic@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: Wed, 8 May 2019 12:06:48 +0200	[thread overview]
Message-ID: <20190508120648.6c40231d.cohuck@redhat.com> (raw)
In-Reply-To: <5c2b74a9-e1d9-cd63-1284-6544fa4376d9@linux.ibm.com>

On Wed, 8 May 2019 11:22:07 +0200
Pierre Morel <pmorel@linux.ibm.com> wrote:

> The TEST command is used to retrieve the status of the I/O-device 
> __path__ and do not go up to the device.
> I did not find clearly that it does not start a data transfer but I 
> really do not think it does.
> May be we should ask people from hardware.
> I only found that test I/O (a specific test command) do not initiate an 
> operation.

FWIW, I'm not sure about what we should do with the test command in any
case.

Currently, I see it defined as a proper command in the rather ancient
"Common I/O Device Commands" (I don't know of any newer public
version), which states that it retrieves the status on the parallel
interface _only_ (and generates a command reject on the serial
interface). IIRC, the parallel interface has been phased out quite some
time ago.

The current PoP, in contrast, defines this as an _invalid_ command
(generating a channel program check).

So, while the test command originally was designed to never initiate a
data transfer, we now have an invalid command in its place, and we
don't know if something else might change in the future (for transfer
mode, a test-like command is already defined in the PoP).

So, the safest course would probably be to handle the ->cda portion and
send the command down. We'll get a check condition on current hardware,
but it should be safe if something changes in the future.

Of course, asking some hardware folks is not a bad idea, either :)

  reply	other threads:[~2019-05-08 10:06 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 [this message]
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
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=20190508120648.6c40231d.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.