On Sat, 10 Apr 2021 at 14:53, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: > > Hi Luc, > > On 4/10/21 3:19 PM, Luc Michel wrote: > > Note that clock propagation during reset has always been a complicated > > problem. Calling clock_propagate is forbidden during the reset's enter > > phase because of the side effects it can introduce. > > Ah... Maybe this is related to the generic reset problem in QEMU :(
I do wonder if we got the clock-propagation-during-reset part of this wrong -- it seemed right to me at the time but trying to use the clock API recently I did run into some unhelpful-seeming results (I forget the details now, though). > > I find your API modification a bit restrictive. I think creating a > > standalone clock can be useful, e.g. in complicated devices that may > > want to use internal "intermediate" clocks. I would not remove this > > possibility to the API users. > > Well, this is the point. I can't see a justification to have a clock > on a non-qdev object. We should be able to model complicated devices > with qdev. The obvious reason is that machine objects are not qdev devices (ie TYPE_MACHINE inherits directly from TYPE_OBJECT, not from TYPE_DEVICE), but it's a reasonable thing to say "this machine has a fixed frequency clock which it connects to the SoC". I do wonder if the right fix to that would be to make TYPE_MACHINE be a subtype of TYPE_DEVICE, though -- machines not being subtypes of device has other annoying effects, like their not having reset methods or being able to register vmstate structs. There might be some unanticipated side effects of making that change, though. thanks -- PMM