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 <afaer...@suse.de> 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
