From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55514) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsskI-0002tP-BI for qemu-devel@nongnu.org; Wed, 09 Jan 2013 05:18:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsskF-00024g-Qb for qemu-devel@nongnu.org; Wed, 09 Jan 2013 05:18:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsskF-00024Y-IN for qemu-devel@nongnu.org; Wed, 09 Jan 2013 05:18:51 -0500 Date: Wed, 9 Jan 2013 12:22:38 +0200 From: "Michael S. Tsirkin" Message-ID: <20130109102238.GC30914@redhat.com> References: <1355761490-10073-1-git-send-email-pbonzini@redhat.com> <877gnovmgj.fsf@codemonkey.ws> <50ED3971.5030600@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50ED3971.5030600@redhat.com> 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: Paolo Bonzini Cc: Peter Maydell , Anthony Liguori , qemu-devel@nongnu.org, Andreas =?iso-8859-1?Q?F=E4rber?= On Wed, Jan 09, 2013 at 10:33:37AM +0100, Paolo Bonzini wrote: > Il 07/01/2013 20:10, Anthony Liguori ha scritto: > > Paolo Bonzini writes: > > > >> 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. > > > > I don't really understand this dual abstraction. I suspect it's > > overgeneralizing something that's the result of poor modeling. > > It's possible. I'll move the SCSI bus away from qdev reset. > Anthony/Michael, can you help doing the same with PCIDevice? And > perhaps Peter and Andreas with sysbus? > > Paolo I'm not sure what would you like to change with PCIDevice. -- MST