From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55139) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtJZU-0005C7-Gz for qemu-devel@nongnu.org; Thu, 10 Jan 2013 09:57:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtJZR-0008RO-Ia for qemu-devel@nongnu.org; Thu, 10 Jan 2013 09:57:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtJZR-0008RJ-Be for qemu-devel@nongnu.org; Thu, 10 Jan 2013 09:57:29 -0500 Date: Thu, 10 Jan 2013 17:01:18 +0200 From: "Michael S. Tsirkin" Message-ID: <20130110150118.GB30731@redhat.com> 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> <87a9shw2ek.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a9shw2ek.fsf@codemonkey.ws> 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: Anthony Liguori Cc: Peter Maydell , qemu-devel@nongnu.org, Andreas =?iso-8859-1?Q?F=E4rber?= , Paolo Bonzini On Thu, Jan 10, 2013 at 08:14:43AM -0600, Anthony Liguori wrote: > 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 I don't think we need a rename to fix a specific bug. The bugs Paolo found can be fixed in virtio and virtio-scsi. > > >> 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