From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34726 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ooc6R-0001NZ-EQ for qemu-devel@nongnu.org; Thu, 26 Aug 2010 09:02:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ooc6M-0007A5-Gj for qemu-devel@nongnu.org; Thu, 26 Aug 2010 09:02:47 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:59726) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ooc6M-00079y-EZ for qemu-devel@nongnu.org; Thu, 26 Aug 2010 09:02:42 -0400 Received: by qyk31 with SMTP id 31so1734447qyk.4 for ; Thu, 26 Aug 2010 06:02:41 -0700 (PDT) Message-ID: <4C7665EE.3090804@codemonkey.ws> Date: Thu, 26 Aug 2010 08:02:38 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qdev: Reset hotplugged devices References: <20100803161914.15514.59304.stgit@localhost6.localdomain6> <1282308092.3860.0.camel@x201> <4C6EA5C9.8080700@codemonkey.ws> <20100825030752.GA14605@valinux.co.jp> <4C7512BF.9000805@codemonkey.ws> <20100825151713.GB16489@valinux.co.jp> <4C75498F.2090006@codemonkey.ws> <20100826083821.GC16489@valinux.co.jp> In-Reply-To: <20100826083821.GC16489@valinux.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Isaku Yamahata Cc: qemu-devel@nongnu.org, Chris Wright , Alex Williamson , glommer@redhat.com, Markus Armbruster On 08/26/2010 03:38 AM, Isaku Yamahata wrote: > >> I think that starts by understanding exactly what's guaranteed and >> understanding what the use cases are for it. >> > Fair enough. How about the followings? > Thanks for enumerating. > This is just a starting point. I borrowed terminology pci/pcie spec. > > > reset > Bring the state of hardware state to consistent state. > (some state might be left unknown.) > > > system reset > a hardware mechanism for setting or returning all hardware states > to the initial conditions. > Use case: > In qemu, system_system_reset(). > > > cold reset(power on reset) > system reset following the application of power. > Use case: > In qemu, system_reset() in main(). > We might want to use this as a power cycle. > When a device is hot plugged, the device should be cold reset too. > This is your motivation. > QEMU_RESET_COLD > Guarantee: > The internal status must be same to qdev_init() + qdev_reset() > This is what we do today in QEMU and from a functional perspective it covers the type of function we need today. > > warm reset > system reset without cycling the supplied power. > Use case: > In qemu, system_reset() in main_loop(). There are many places > which calls qemu_system_reset_request(). > Some state are retained across warm reset. Like PCIe AER, error > reporting registers need to keep its contents across warm reset > as OS would examine them and report it when hardware errors caused > warm reset. > QEMU_RESET_WARM > With AER, I can't imagine that this matters that much unless we're doing PCI passthrough, right? So maybe the way we should frame this discussion is, what's the type of reset semantics that we need to support for PCI passthrough? The next question after that is how do we achieve the different types of reset for passthrough devices? BTW, if you could transfer some of this discussion to a wiki page on qemu.org, I think that would be extremely valuable. Regards, Anthony Liguori > bus reset > Reset bus and devices on the bus. > Bus reset is usually triggered when cold reset, warm reset and > commanding the bus controller to reset the child bus. > When bus reset is triggered as command to bus controller, > the effect is usually same to warm reset on devices on the bus. > > Typically on parallel bus, bus reset is started by asserting > a designated signal. > Example: PCI RST#, ATA RESET-, SCSI RST > > Use case: > bus reset as result of programming bus controller. > Qemu is currently missing it which I'd like to fill for pci bus. > ATA and SCSI could benefit from this. > QEMU_RESET_WARM with bus. > Guarantee: > device state under the bus is same as warm reset. > > > device/function reset: > Reset triggered by sending reset command to a device. > This is bus/device specific. > There might be many reset commands whose effects are different. > Example: PCI FLR, ATA DEVICE RESET command, > scsi bus device reset message. > > This reset is bus specific, so it wouldn't be suitable for qdev > frame work and could be handled by each bus level. > > > hot reset: > I just put it here for completeness because pcie defines hot reset. > A reset propagated in-band across a Link using a Physical Layer > mechanism. > Qemu doesn't emulate physical layer, so we don't care it. > From software point of view, hot reset has same effect to warm reset. > >