On Tue, 8 May 2018 16:24:08 +0200 Halil Pasic <pa...@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 <pa...@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.
