mbox series

[v3,0/2] vfio-ccw: support hsch/csch (QEMU part)

Message ID 20190301093949.27955-1-cohuck@redhat.com (mailing list archive)
Headers show
Series vfio-ccw: support hsch/csch (QEMU part) | expand

Message

Cornelia Huck March 1, 2019, 9:39 a.m. UTC
[This is the QEMU part, git tree is available at
https://github.com/cohuck/qemu vfio-ccw-caps

The companion Linux kernel patches are available at
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw.git vfio-ccw-eagain-caps-v4]

Currently, vfio-ccw only relays START SUBCHANNEL requests to the real
device. This tends to work well for the most common 'good path' scenarios;
however, as we emulate {HALT,CLEAR} SUBCHANNEL in QEMU, things like
clearing pending requests at the device is currently not supported.
This may be a problem for e.g. error recovery.

This patch series makes use of the newly introduced async command region
to issue hsch/csch; if it is not present, continue to emulate hsch/csch,
as before.

Note that the kernel side now returns -EAGAIN to trigger a retry in more
cases; QEMU should already be fine with that.

[I'm not quite happy with how this async processing hooks up in css.c;
ideas welcome.]

Lightly tested (I can interact with a dasd as before, and reserve/release
seems to work well.) Not sure if there is a better way to test this, ideas
welcome.


Changes v2->v3:
- update kernel header to v4 of kernel patches
- rebased on master
Changes v1->v2:
- update kernel header to v2 of kernel patches
- rebased on master

Cornelia Huck (2):
  vfio-ccw: new capability chain support
  vfio-ccw: support async command subregion

 hw/s390x/css.c                 |  27 ++++++--
 hw/vfio/ccw.c                  | 109 ++++++++++++++++++++++++++++++++-
 include/hw/s390x/s390-ccw.h    |   3 +
 linux-headers/linux/vfio.h     |   4 ++
 linux-headers/linux/vfio_ccw.h |  12 ++++
 5 files changed, 149 insertions(+), 6 deletions(-)

Comments

Eric Farman March 22, 2019, 1:49 a.m. UTC | #1
On 3/1/19 4:39 AM, Cornelia Huck wrote:
> 
> [I'm not quite happy with how this async processing hooks up in css.c;
> ideas welcome.]

I guess I'm not unhappy with it, but it does look a little odd.  Not 
sure I have a better idea right now...  Will ponder that for a while.

  - Eric
Cornelia Huck April 2, 2019, 1:44 p.m. UTC | #2
On Thu, 21 Mar 2019 21:49:54 -0400
Eric Farman <farman@linux.ibm.com> wrote:

> On 3/1/19 4:39 AM, Cornelia Huck wrote:
> > 
> > [I'm not quite happy with how this async processing hooks up in css.c;
> > ideas welcome.]  
> 
> I guess I'm not unhappy with it, but it does look a little odd.  Not 
> sure I have a better idea right now...  Will ponder that for a while.

If we don't come up with something better right now, we can still change
this later, I think.