On Tue, Dec 18, 2012 at 09:35:02AM +0100, Paolo Bonzini wrote: > Il 18/12/2012 08:27, Paolo Bonzini ha scritto: > > Il 17/12/2012 22:43, Michael S. Tsirkin ha scritto: > >> On Mon, Dec 17, 2012 at 05:24:35PM +0100, Paolo Bonzini wrote: > >>> After discussion with mst on the topic of resetting virtio devices, > >>> here is a series that hopefully clarifies the semantics of bus and > >>> device resets. > >>> > >>> After this series, there are two kinds of resets: > >> > >> So just to clarify, what I proposed was this > >> (on top of my type safety patch). Then > >> all transports can call virtio_config_reset > >> when appropriate (e.g. when PA is set to 0). > >> > >> Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > >> > >> diff --git a/hw/virtio.c b/hw/virtio.c > >> index f40a8c5..e65d7c8 100644 > >> --- a/hw/virtio.c > >> +++ b/hw/virtio.c > >> @@ -554,6 +554,14 @@ void virtio_reset(void *opaque) > >> } > >> } > >> > >> +/* Device-specific reset through virtio config space. > >> + * Reset virtio config and backend child devices if any. > >> + */ > >> +void virtio_config_reset(VirtIODevice *vdev) > >> +{ > >> + qdev_reset_all(vdev->binding_opaque); > >> +} > > > > Yes, I had understood. As I said, this is the wrong direction. > > Resetting happens from vdev->binding_opaque, it can just do > > qdev_reset_all(myself).
It can but it's the wrong thing for transport to know about. Let PCI worry about PCI things. This is not a transport specific thing so belongs in virtio.c > ... besides, this only works if the reset callback of > vdev->binding_opaque remembers to call virtio_reset (in the s390 > bindings, it doesn't and this series fixes it). That's a separate bug I think. > So IMO it is not only > useless, it is also misleading. > > Paolo