From: Cornelia Huck <cohuck@redhat.com> To: Halil Pasic <pasic@linux.ibm.com>, Eric Farman <farman@linux.ibm.com>, Farhan Ali <alifm@linux.ibm.com>, Pierre Morel <pmorel@linux.ibm.com> Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, Cornelia Huck <cohuck@redhat.com>, Alex Williamson <alex.williamson@redhat.com>, qemu-devel@nongnu.org, qemu-s390x@nongnu.org Subject: [PATCH v3 0/2] vfio-ccw: support hsch/csch (QEMU part) Date: Fri, 1 Mar 2019 10:39:47 +0100 [thread overview] Message-ID: <20190301093949.27955-1-cohuck@redhat.com> (raw) [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(-) -- 2.17.2
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com> To: Halil Pasic <pasic@linux.ibm.com>, Eric Farman <farman@linux.ibm.com>, Farhan Ali <alifm@linux.ibm.com>, Pierre Morel <pmorel@linux.ibm.com> Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, qemu-devel@nongnu.org, qemu-s390x@nongnu.org, Alex Williamson <alex.williamson@redhat.com>, Cornelia Huck <cohuck@redhat.com> Subject: [Qemu-devel] [PATCH v3 0/2] vfio-ccw: support hsch/csch (QEMU part) Date: Fri, 1 Mar 2019 10:39:47 +0100 [thread overview] Message-ID: <20190301093949.27955-1-cohuck@redhat.com> (raw) [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(-) -- 2.17.2
next reply other threads:[~2019-03-01 9:39 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-01 9:39 Cornelia Huck [this message] 2019-03-01 9:39 ` [Qemu-devel] [PATCH v3 0/2] vfio-ccw: support hsch/csch (QEMU part) Cornelia Huck 2019-03-01 9:39 ` [PATCH v3 1/2] vfio-ccw: new capability chain support Cornelia Huck 2019-03-01 9:39 ` [Qemu-devel] " Cornelia Huck 2019-03-21 20:19 ` Eric Farman 2019-03-01 9:39 ` [PATCH v3 2/2] vfio-ccw: support async command subregion Cornelia Huck 2019-03-01 9:39 ` [Qemu-devel] " Cornelia Huck 2019-03-22 1:38 ` Eric Farman 2019-04-02 13:42 ` Cornelia Huck 2019-04-02 13:42 ` [Qemu-devel] " Cornelia Huck 2019-03-22 1:49 ` [PATCH v3 0/2] vfio-ccw: support hsch/csch (QEMU part) Eric Farman 2019-04-02 13:44 ` Cornelia Huck 2019-04-02 13:44 ` [Qemu-devel] " 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=20190301093949.27955-1-cohuck@redhat.com \ --to=cohuck@redhat.com \ --cc=alex.williamson@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 \ --cc=qemu-devel@nongnu.org \ --cc=qemu-s390x@nongnu.org \ /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: linkBe 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.