From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULPRf-0005qe-4a for qemu-devel@nongnu.org; Thu, 28 Mar 2013 22:53:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ULPRd-0006UX-WD for qemu-devel@nongnu.org; Thu, 28 Mar 2013 22:53:35 -0400 Received: from mail-ea0-x234.google.com ([2a00:1450:4013:c01::234]:43424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULPRd-0006UR-Ox for qemu-devel@nongnu.org; Thu, 28 Mar 2013 22:53:33 -0400 Received: by mail-ea0-f180.google.com with SMTP id d10so53647eaj.11 for ; Thu, 28 Mar 2013 19:53:32 -0700 (PDT) Date: Fri, 29 Mar 2013 03:49:58 +0100 From: "Edgar E. Iglesias" Message-ID: <20130329024958.GB4021@smtp.vpn> References: <51348D97.4060400@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Qemu-devel] [RFC PATCH v1 0/7] Reset and Halting modifications + Zynq SMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , Anthony Liguori , Juan Quintela , qemu-devel@nongnu.org, dantesu@faraday-tech.com, Andreas =?iso-8859-1?Q?F=E4rber?= Hi On Mon, Mar 04, 2013 at 10:57:49PM +1000, Peter Crosthwaite wrote: > Hi Andreas, > > On Mon, Mar 4, 2013 at 10:03 PM, Andreas Färber wrote: > > Hi Peter, > > > > Am 04.03.2013 10:01, schrieb Peter Crosthwaite: > >> Hi All. The clock controller module in the Zynq platform has the ability to halt > >> and reset arbitrary devices, including the CPU. We use this feature to implement > >> SMP Linux - the kernel halts CPU1 then rewrites the vector table to the > >> secondary entry point and unhalts. > >> > >> The clock controller however is reasonable generic, in that in has the ability > >> to halt and reset any arbitrary device in the Zynq SoC. The interface for doing > >> this is reasonably consistent. So im looking for unified way to halt and reset > >> arbitrary devices CPUs included. So given we already have reset() defined on the > >> TYPE_DEVICE level, i've added halt as well. > >> > >> This series is based on v3 of the current qom-cpu queue to pick up the move of > >> cpu halt out of the env. From this I attach the cpu::halted bit to the > >> Device::(un)halt function. > > > > I have doubts whether that is a suitable API... My initial thought was: > > Isn't that pretty much realize/unrealize according to Anthony's > > definition via Vcc? > > Loss of Vcc generally implies loss of state (unless your device state > is non volatile storage) which is not what I am going for. I'm trying > to suspend for later resumption. Could we hook up the cpu::halted bit > to unrealize/realize and it would work? > > The technical difference I see is that in your case > > devices are still migrated, not sure if that makes a difference, > > assuming unhalt/realize puts them into a defined state (i.e., reset). > > > > The defined state for unhalt is exactly what it was when you halted. > Not sure of the migration issues here. IMO, you'd need to migrate the gated state. For hotunplug you wouldn't want to migrate I guess. Regarding the framework a thought is that in the future we might need to propagte more detailed info about clocks. Not only gated or enabled, but maybe also frequencies. Most models in QEMU don't care but for example timers that change their timing depending on clock-tree setup might benefit. It would also make it possible to trap guest errors when for example using I/O with wrong clock setups. Best regards, Edgar