All of lore.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 0/7] s390: vfio-ccw fixes
Date: Wed, 15 May 2019 14:45:30 +0200	[thread overview]
Message-ID: <20190515144530.5603097b.cohuck@redhat.com> (raw)
In-Reply-To: <20190514234248.36203-1-farman@linux.ibm.com>

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

> The attached are a few fixes to the vfio-ccw kernel code for potential
> errors or architecture anomalies.  Under normal usage, and even most
> abnormal usage, they don't expose any problems to a well-behaved guest
> and its devices.  But, they are deficiencies just the same and could
> cause some weird behavior if they ever popped up in real life.
> 
> I have tried to arrange these patches in a "solves a noticeable problem
> with existing workloads" to "solves a theoretical problem with
> hypothetical workloads" order.  This way, the bigger ones at the end
> can be discussed without impeding the smaller and more impactful ones
> at the start.
> 
> Per the conversations on patch 7, the last several patches remain
> unchanged.  They continue to buid an IDAL for each CCW, and only pin
> guest pages and assign the resulting addresses to IDAWs if they are
> expected to cause a data transfer.  This will avoid sending an
> unmodified guest address, which may be invalid but anyway is not mapped
> to the same host address, in the IDAL sent to the channel subsystem and
> any unexpected behavior that may result.
> 
> They are based on 5.1.0, not Conny's vfio-ccw tree even though there are
> some good fixes pending for 5.2 there.  I've run this series both with
> and without that code, but couldn't decide which base would provide an
> easier time applying patches.  "I think" they should apply fine to both,
> but I apologize in advance if I guessed wrong!  :)

They also should apply on current master, no? My 5.2 branch should be
all merged by now :)

Nothing really jumped out at me; I'm happy to queue the patches if I
get some more feedback.

> 
> 
> Changelog:
>  v1 -> v2:
>   - Patch 1:
>      - [Cornelia] Added a code comment about why we update the SCSW when
>        we've gone past the end of the chain for normal, successful, I/O
>   - Patch 2:
>      - [Cornelia] Cleaned up the cc info in the commit message
>      - [Pierre] Added r-b
>   - Patch 3:
>      - [Cornelia] Update the return code information in prologue of
>        pfn_array_pin(), and then only call vfio_unpin_pages() if we
>        pinned anything, rather than silently creating an error
>        (this last bit was mentioned on patch 6, but applied here)
>      - [Eric] Clean up the error exit in pfn_array_pin()
>   - Patch 4-7 unchanged
> 
> Eric Farman (7):
>   s390/cio: Update SCSW if it points to the end of the chain
>   s390/cio: Set vfio-ccw FSM state before ioeventfd
>   s390/cio: Split pfn_array_alloc_pin into pieces
>   s390/cio: Initialize the host addresses in pfn_array
>   s390/cio: Allow zero-length CCWs in vfio-ccw
>   s390/cio: Don't pin vfio pages for empty transfers
>   s390/cio: Remove vfio-ccw checks of command codes
> 
>  drivers/s390/cio/vfio_ccw_cp.c  | 159 +++++++++++++++++++++++---------
>  drivers/s390/cio/vfio_ccw_drv.c |   6 +-
>  2 files changed, 119 insertions(+), 46 deletions(-)
> 

  parent reply	other threads:[~2019-05-15 12:45 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
2019-05-15 12:45 ` Cornelia Huck [this message]
2019-05-15 13:21   ` [PATCH v2 0/7] s390: vfio-ccw fixes 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=20190515144530.5603097b.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.