From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtIvu-0006mS-VV for qemu-devel@nongnu.org; Thu, 10 Jan 2013 09:16:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtIvr-0006Z9-PC for qemu-devel@nongnu.org; Thu, 10 Jan 2013 09:16:38 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:39263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtIvr-0006Z4-LE for qemu-devel@nongnu.org; Thu, 10 Jan 2013 09:16:35 -0500 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 10 Jan 2013 09:16:34 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 8DE596E8066 for ; Thu, 10 Jan 2013 09:14:48 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0AEEm5k279898 for ; Thu, 10 Jan 2013 09:14:49 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0AEElVf012399 for ; Thu, 10 Jan 2013 12:14:48 -0200 From: Anthony Liguori In-Reply-To: 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> Date: Thu, 10 Jan 2013 08:14:43 -0600 Message-ID: <87a9shw2ek.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 , Paolo Bonzini Cc: qemu-devel@nongnu.org, Andreas =?utf-8?Q?F=C3=A4rber?= , mst@redhat.com Peter Maydell writes: > 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. > > 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). The challenge is how we go from what we have to what we want. Right now we have DeviceState::reset. This is used both as a soft and hard reset. What I would propose is that we: s/DeviceState::reset/DeviceState::hard_reset/g Then introduce PCIDevice::soft_reset. We can convert the PCI layer to call soft_reset() instead of hard_reset. Over time, it would be great if we could find a way to implement hard_reset in terms of device destruction/recreation but we're not there yet. I think the reset/hard_reset rename can be done via sed mostly. Would this solve the bug that you're trying to fix Michael/Paolo? Regards, Anthony Liguori >> 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? > > -- PMM