From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tss2c-0004L8-1n for qemu-devel@nongnu.org; Wed, 09 Jan 2013 04:33:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tss2a-0007cy-1X for qemu-devel@nongnu.org; Wed, 09 Jan 2013 04:33:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:14929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tss2Z-0007cs-Nu for qemu-devel@nongnu.org; Wed, 09 Jan 2013 04:33:43 -0500 Message-ID: <50ED3971.5030600@redhat.com> Date: Wed, 09 Jan 2013 10:33:37 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1355761490-10073-1-git-send-email-pbonzini@redhat.com> <877gnovmgj.fsf@codemonkey.ws> In-Reply-To: <877gnovmgj.fsf@codemonkey.ws> 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: Anthony Liguori Cc: Peter Maydell , qemu-devel@nongnu.org, =?ISO-8859-1?Q?Andreas_F=E4rber?= , mst@redhat.com 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