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(-)
next prev parent 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