From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkdV5-0008Cl-BI for qemu-devel@nongnu.org; Mon, 17 Dec 2012 11:25:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkdV3-00088l-Jt for qemu-devel@nongnu.org; Mon, 17 Dec 2012 11:25:07 -0500 Received: from mail-ia0-f173.google.com ([209.85.210.173]:55089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkdV3-00087V-Bz for qemu-devel@nongnu.org; Mon, 17 Dec 2012 11:25:05 -0500 Received: by mail-ia0-f173.google.com with SMTP id w21so5709444iac.4 for ; Mon, 17 Dec 2012 08:25:02 -0800 (PST) Sender: Paolo Bonzini From: Paolo Bonzini Date: Mon, 17 Dec 2012 17:24:35 +0100 Message-Id: <1355761490-10073-1-git-send-email-pbonzini@redhat.com> Subject: [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: qemu-devel@nongnu.org Cc: aliguori@us.ibm.com, mst@redhat.com 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: 1) device-level reset is the kind of reset that you get with a register write on the device. It will clear interrupts and DMAs among other things, but not any bus-level state, for example it will not clear PCI BARs and other configuration space data. It is done with qdev_reset_all. 2) bus-level reset is the kind of reset that you get with a register write on the device that exports the bus (including triggering a device-level reset on the device that exports the bus). It will do a device-level reset on the child, but also clear bus-level state such as PCI BARs and other configuration space data. It can be triggered for all devices on a bus with qbus_reset_all. There is still no API for a bus-level reset of a single device (like PCI FLR), this can be added later. Patches 1-5 are miscellaneous fixes to the reset paths. Patches 6-8 introduce qbus_reset_all and uses it. Patches 9-12 switch qdev_reset_all and qbus_reset_all from pre-order to post-order, and document the resulting semantics. Finally, patches 13-15 adjust the virtio implementations to use qdev device-level reset more extensively. Paolo Bonzini (15): qdev: do not reset a device until the parent has been initialized intel-hda: do not reset codecs from intel_hda_reset pci: clean up resetting of IRQs virtio-pci: reset device before PCI layer virtio-s390: add a reset function to virtio-s390 devices qdev: add qbus_reset_all pci: do not export pci_bus_reset lsi: use qbus_reset_all to reset SCSI bus qdev: allow both pre- and post-order vists in qdev walking functions qdev: switch reset to post-order qdev: remove device_reset qdev: document reset semantics virtio-pci: reset all qbuses too when writing to the status field virtio-s390: reset all qbuses too when writing to the status field virtio-serial: do not perform bus reset by hand hw/intel-hda.c | 1 - hw/lsi53c895a.c | 7 +---- hw/pci.c | 16 ++++------ hw/pci.h | 1 - hw/pci_bridge.c | 2 +- hw/qdev-core.h | 83 ++++++++++++++++++++++++++++++++++++++++++-------- hw/qdev.c | 70 +++++++++++++++++++++++++++--------------- hw/s390-virtio-bus.c | 16 +++++++++- hw/virtio-pci.c | 27 +++++++--------- hw/virtio-serial-bus.c | 19 +++--------- 10 files changed, 156 insertions(+), 86 deletions(-) -- 1.8.0.2