From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkvXZ-00061j-9x for qemu-devel@nongnu.org; Tue, 18 Dec 2012 06:40:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkvXR-0007re-PL for qemu-devel@nongnu.org; Tue, 18 Dec 2012 06:40:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkvXR-0007qc-Di for qemu-devel@nongnu.org; Tue, 18 Dec 2012 06:40:45 -0500 Message-ID: <50D05634.1010401@redhat.com> Date: Tue, 18 Dec 2012 12:40:36 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1355761490-10073-1-git-send-email-pbonzini@redhat.com> <20121217214336.GA11991@redhat.com> <50D01AEE.2010508@redhat.com> <50D02AB6.9050208@redhat.com> <20121218094913.GC19090@redhat.com> In-Reply-To: <20121218094913.GC19090@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org Il 18/12/2012 10:49, Michael S. Tsirkin ha scritto: >>>> +/* 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. The transport provides an implementation of dc->reset, not virtio.c (e.g. virtio_pci_reset). Sure it knows what the effect of qdev_reset_all are on itself. > Let PCI worry about PCI things. This is not > a transport specific thing so belongs in virtio.c This _is_ a transport specific thing. Sure it will reset the virtio device (virtio_reset), but it will also reset things such as MSI-X vectors and VIRTIO_PCI_FLAG_BUS_MASTER_BUG. It doesn't belong 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. Yes, I agree. Paolo