From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50282) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtHVz-0007RO-Mx for qemu-devel@nongnu.org; Thu, 10 Jan 2013 07:45:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtHVt-0006iK-On for qemu-devel@nongnu.org; Thu, 10 Jan 2013 07:45:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtHVt-0006iE-GV for qemu-devel@nongnu.org; Thu, 10 Jan 2013 07:45:41 -0500 Message-ID: <50EEB7EF.1010104@redhat.com> Date: Thu, 10 Jan 2013 13:45:35 +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> 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 13:31, Peter Maydell ha scritto: > On 10 January 2013 12:12, Paolo Bonzini wrote: >> Il 10/01/2013 12:59, Peter Maydell ha scritto: >>>>>>>>>>> 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? >>>>>>> What does it even mean to reset a sysbus? Do we do it anywhere? >>>>>>> (it looks like vl.c does, just as a shortcut so memory mapped devices >>>>>>> get their reset hooks called?) >>> So how should it work instead? I kind of feel like all qdev devices should >>> get their reset hook called on machine reset, regardless of bus [since it's >>> modelling power cycling the whole system], but would that break >>> something? >> >> 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. > 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. Paolo