Re: [Qemu-devel] [PATCH 0/2] s390x: reset handling for ccw devices

[Cornelia Huck <cohuck@redhat.com>]

On Tue, 8 May 2018 16:24:08 +0200
Halil Pasic <pasic@linux.ibm.com> wrote:

> On 05/08/2018 03:55 PM, Cornelia Huck wrote:
> > On Tue, 8 May 2018 15:29:50 +0200
> > Halil Pasic <pasic@linux.ibm.com> wrote:

> >> In particular the the pim, the lpm and the pam set in css_reset_sch
> >> seems to suit only devices that use the virtual chp. That
> >> is it ain't suits any CCWDevice instance.  
> > 
> > Yes, we need to revisit this code and split out what makes sense and
> > what doesn't. For now, we only have virtual devices and vfio-ccw, so
> > we're fine. It even might make sense to keep them separate in the
> > future, as having a virtual device and one only mirroring some state in
> > QEMU sound like they want to be handled differently.
> >   
> 
> I agree. The last sentence probably means that resetting the in QEMU
> state may not be sufficient.

We currently have vfio-ccw's reset handler calling into the kernel and
triggering an disable/enable. What's missing is resetting QEMU's
internal state (or rather, syncing it up with the hardware state).
Needs some thinking.

> Another to me somewhat strange thing I noticed is this disabled_cb
> used by virtio. It's is I guess the way it it is (specified in
> the OASIS spec and everything), but I don't really understand how
> this aligns with what the PoP says about MSCH. I mean AFAIU
> MSCH does not trigger any communication between the channel subsystem
> and the CU and or the device. I read the PoP as nothing is supposed
> to change expect the things specified where MSCH is described. I guess
> it is just another strange thing we have to live with -- for historical
> reasons.

OTOH, I'd expect to have to setup things again if I disabled and
afterwards enabled a subchannel again. We should be able to overwrite
any old state after doing that. This was the best way to get virtio to
start with a clean slate again -- we don't want virtio reset to clean
the revision.