+Mark & Igor On 4/10/21 5:15 PM, Peter Maydell wrote: > On Sat, 10 Apr 2021 at 14:53, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: >> 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".
In this series I restrict Clocks to 1/ qdev and 2/ MachineState (which is the case you described). I tried to think about all the hardware I worked with and all could be somehow modeled as qdev. > 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. Yes, that would simplify few things. I might try it. Expanding the topic, this reminds me a discussion between Igor and Mark about MemoryRegion... One was about we can not change the NULL owner to MachineState because the region could be migrated and there is a mismatch. Another was about preparing the design for multi-arch machines, Mark was confuse by having owner for memory regions such DRAM because on a board they aren't owned, can be used by various masters (CPUs, DMA). So the machine should be the owner somehow. Maybe the problem was with migration indeed, I can't remember :S Regards, Phil.
