public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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(-)  
> >   
> 


  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