From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtIFD-0000Fs-Ip for qemu-devel@nongnu.org; Thu, 10 Jan 2013 08:32:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtIF7-00022y-Nv for qemu-devel@nongnu.org; Thu, 10 Jan 2013 08:32:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtIF7-00022l-GD for qemu-devel@nongnu.org; Thu, 10 Jan 2013 08:32:25 -0500 Message-ID: <50EEC2DF.30708@redhat.com> Date: Thu, 10 Jan 2013 14:32:15 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1355761490-10073-1-git-send-email-pbonzini@redhat.com> <877gnovmgj.fsf@codemonkey.ws> <50ED3971.5030600@redhat.com> <50EEAA5F.8060900@redhat.com> <50EEB045.6080908@redhat.com> <50EEB7EF.1010104@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Peter Maydell Cc: Anthony Liguori , qemu-devel@nongnu.org, =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , mst@redhat.com Il 10/01/2013 14:01, Peter Maydell ha scritto: > On 10 January 2013 12:45, Paolo Bonzini wrote: >> Il 10/01/2013 13:31, Peter Maydell ha scritto: >>> On 10 January 2013 12:12, Paolo Bonzini wrote: >>>> It's just an implementation detail. Right now we have a common >>>> callback. The idea is to give each bus its own callback. In the case >>>> of sysbus it would just call a method; for PCI it would reset some >>>> configuration and then call a method; for SCSI there is no need to call >>>> a method at all; and so on. >>> >>> But machine reset shouldn't call bus specific PCI or SCSI reset >>> methods -- we've just effectively yanked the power to the VM >>> so everything should just reset as if it was freshly constructed. >> >> Yes, but we do not have a way to do that, so QEMU resorts to a warm reset. > > qdev reset is cold reset, not warm reset. Whatever. :) It resorts to a reset (as if it was freshly constructed) instead of _really_ doing a fresh construction. >>> A bus-specific reset method would be for buses where the bus >>> itself has some sort of guest-triggerable reset (by prodding the >>> chipset, for instance). >> >> Yes. >> >>>> In addition, navigating the qdev tree should be explicit in the methods. >>>> It will not happen anymore via the "magic" qdev_reset_all. >>> >>> *Something* has to say "call reset for every qdev object in the >>> system", surely? >> >> It will call it on sysbus, which will call it on every sysbus child. >> Devices that have a child bus will propagate it further down. > > This doesn't work when we get rid of the idea that every qdev > device is attached to a tree of buses. At least for now, devices that should be bus-free are sysbus devices, aren't they? Paolo