From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsJBh-00067T-0b for qemu-devel@nongnu.org; Mon, 07 Jan 2013 15:20:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsJBf-0000qX-IH for qemu-devel@nongnu.org; Mon, 07 Jan 2013 15:20:48 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:48579) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsJBf-0000qP-BN for qemu-devel@nongnu.org; Mon, 07 Jan 2013 15:20:47 -0500 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 7 Jan 2013 15:20:45 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 5DDD86E803F for ; Mon, 7 Jan 2013 15:20:42 -0500 (EST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r07KKgow330536 for ; Mon, 7 Jan 2013 15:20:42 -0500 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r07KKfvL014180 for ; Mon, 7 Jan 2013 13:20:41 -0700 From: Anthony Liguori In-Reply-To: References: <1355761490-10073-1-git-send-email-pbonzini@redhat.com> <877gnovmgj.fsf@codemonkey.ws> Date: Mon, 07 Jan 2013 14:20:35 -0600 Message-ID: <87mwwkg2y4.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Peter Maydell Cc: Paolo Bonzini , qemu-devel@nongnu.org, mst@redhat.com Peter Maydell writes: > On 7 January 2013 19:10, Anthony Liguori wrote: >> Paolo Bonzini writes: >>> 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. > > This isn't really right -- often writing the register on the device will > reset some things but not the whole device state the way a qdev > reset does. qdev reset (to the extent it's modelling anything) is more > like yanking power to the device and reapplying it. > >>> 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. > > This doesn't sound very plausible: when would you do a bus level > reset anyway? > >> I don't really understand this dual abstraction. I suspect it's >> overgeneralizing something that's the result of poor modeling. > > Agreed. > >> What I'm missing with this series is what problem are we trying to >> solve? I don't think we model reset correctly today because I don't >> think there's a single notion of reset. > > Also agreed. > >> I think reset really ought to just be a bus level concept with >> individual implementations for each bus. > > I'm not sure I really agree here, especially since QOM/qdev are > moving away from the idea that there is a single bus tree and every > device is on a single bus. I don't mean a BusState level concept, I mean a PCIBus concept. There is clearly such a thing as a PCI bus reset. In fact, there are multiple types of PCI bus resets. There should be a PCIBus method that calls out to PCIDevices on the bus. But that isn't something that should be fitted into generalized to a BusState::reset method. > It's quite common for a bus to include a > reset signal but not all device reset is handled by a signal on a bus. Agreed. > > If we want to model reset properly we should model actual reset > lines (and/or power-cycling). If we don't care we can continue with > whatever fudge we like :-) Yes, and that's basically what qemu_system_reset() is. Of course, we model it like everything is directly connected to a single power source which is true 99% of the time. That's why we've gotten away with it for so long. Regards, Anthony Liguori > -- PMM