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 5/7] s390/cio: Allow zero-length CCWs in vfio-ccw
Date: Wed, 15 May 2019 14:23:39 +0200	[thread overview]
Message-ID: <20190515142339.12065a1d.cohuck@redhat.com> (raw)
In-Reply-To: <20190514234248.36203-6-farman@linux.ibm.com>

On Wed, 15 May 2019 01:42:46 +0200
Eric Farman <farman@linux.ibm.com> wrote:

> It is possible that a guest might issue a CCW with a length of zero,
> and will expect a particular response.  Consider this chain:
> 
>    Address   Format-1 CCW
>    --------  -----------------
>  0 33110EC0  346022CC 33177468
>  1 33110EC8  CF200000 3318300C
> 
> CCW[0] moves a little more than two pages, but also has the
> Suppress Length Indication (SLI) bit set to handle the expectation
> that considerably less data will be moved.  CCW[1] also has the SLI
> bit set, and has a length of zero.  Once vfio-ccw does its magic,
> the kernel issues a start subchannel on behalf of the guest with this:
> 
>    Address   Format-1 CCW
>    --------  -----------------
>  0 021EDED0  346422CC 021F0000
>  1 021EDED8  CF240000 3318300C
> 
> Both CCWs were converted to an IDAL and have the corresponding flags
> set (which is by design), but only the address of the first data
> address is converted to something the host is aware of.  The second
> CCW still has the address used by the guest, which happens to be (A)
> (probably) an invalid address for the host, and (B) an invalid IDAW
> address (doubleword boundary, etc.).
> 
> While the I/O fails, it doesn't fail correctly.  In this example, we
> would receive a program check for an invalid IDAW address, instead of
> a unit check for an invalid command.
> 
> To fix this, revert commit 4cebc5d6a6ff ("vfio: ccw: validate the
> count field of a ccw before pinning") and allow the individual fetch
> routines to process them like anything else.  We'll make a slight
> adjustment to our allocation of the pfn_array (for direct CCWs) or
> IDAL (for IDAL CCWs) memory, so that we have room for at least one
> address even though no data will be transferred.
> 
> Note that this doesn't provide us with a channel program that will
> fail in the expected way.  Since our length is zero, vfio_pin_pages()
> returns -EINVAL and cp_prefetch() will thus fail.  This will be fixed
> in the next patch.

So, this failed before, and still fails, just differently? IOW, this
has no effect on bisectability?

> 
> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> ---
>  drivers/s390/cio/vfio_ccw_cp.c | 26 ++++++++------------------
>  1 file changed, 8 insertions(+), 18 deletions(-)

  reply	other threads:[~2019-05-15 12:23 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 [this message]
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
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=20190515142339.12065a1d.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