On Tue, 4 Dec 2018 13:38:10 +0100 Halil Pasic <pasic@xxxxxxxxxxxxx> wrote: > On Thu, 22 Nov 2018 17:54:29 +0100 > Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > > > [This is the Linux kernel part, git tree is available at > > https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw.git vfio-ccw-caps > > > > The companion QEMU patches are available at > > https://github.com/cohuck/qemu vfio-ccw-caps] > > > > 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. > > I'm wondering: what about MODIFY SUBCHANNEL? Do we plan to add MSCH > as well or is it supposed to remain 'userspace emulated'? AFAIR MSCH > may have an effect on error recovery as well. I think that would require a deeper change, as we have the requirement to enable the subchannel before handing it to userspace. IOW, the guest does not cause the subchannel to be enabled/disabled, but the host does. Parameters (like for channel measurements) are a different game. It is something we should look into, but it will need a different region. > BTW I would like to have the concurrency discussion sorted out before > I proceed with my review, because reviewing the stuff without a fair idea > of what exactly are we trying to achieve would yield poor results. I'm not sure what is unclear about what we're trying to achieve (enable the guest to issue halt/clear on real hardware)? But yes, we need to sort out that concurrency thing; I'm currently unsure if the core should do some things as well or if it's more of a vendor-driver thing.
