From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35110 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ooc8P-0002Fs-GS for qemu-devel@nongnu.org; Thu, 26 Aug 2010 09:04:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ooc8O-0007aW-2Z for qemu-devel@nongnu.org; Thu, 26 Aug 2010 09:04:49 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:38203) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ooc8N-0007aP-Um for qemu-devel@nongnu.org; Thu, 26 Aug 2010 09:04:48 -0400 Received: by qwh5 with SMTP id 5so1632300qwh.4 for ; Thu, 26 Aug 2010 06:04:47 -0700 (PDT) Message-ID: <4C76666C.7020106@codemonkey.ws> Date: Thu, 26 Aug 2010 08:04:44 -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, Alex Williamson , glommer@redhat.com, Markus Armbruster On 08/26/2010 03:38 AM, Isaku Yamahata wrote: > > QEMU_RESET_COLD > BTW, just from a implementation perspective, I'd rather have multiple reset callbacks in qdev instead of having a single callback with a type flag. A type flag implies that every callback has to handle all cases whereas with separate callbacks, if a device doesn't implement warm_reset we can easily default it to reset (which is a cold reset). Regards, Anthony Liguori > Guarantee: > The internal status must be same to qdev_init() + qdev_reset() > > > 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 > > > 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. > >