Re: [qemu-s390x] [PATCH 0/3] vfio-ccw: support hsch/csch (kernel part)

[Cornelia Huck]

On Tue, 4 Dec 2018 13:38:10 +0100
Halil Pasic <address@hidden> wrote:

> On Thu, 22 Nov 2018 17:54:29 +0100
> Cornelia Huck <address@hidden> 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.