On 17 September 2018 at 01:40, <damien.he...@greensocs.com> wrote: > Regarding the migration strategy, clocks do not hold the clock state > internally, so there is nothing to migrate there. The consequence is that > a device must update its output clocks in its post_load to propagate the > migrated clock state. This allows migration from old-qemu-with-no-clock > to new-qemu-with-clock-support: newly added clocks will be correctly > initialized during migration. > But it is more complex for input clocks handling: there is no order > guarantee between a device state migration and the update of its inputs clocks > which will occur during other device state migrations. > I think that, for most the cases, this does not rise problems, although there > might be some jitter/glitch during migration before hitting the right value > (with consequences such as the baudrate of a character device changing several > times during migration, I don't think it is a problem but may well be wrong > here).
This doesn't seem like a good idea to me, since as you say there is no guarantee on migration order. It breaks a general principle that devices should migrate their own state and not do anything that disturbs other devices. There are several possible approaches here I think: (1) the "clock" object holds no internal state; if a device on the destination end of a clock connection cares about clock state then it keeps and updates a copy of that state when the callback is called, and it is responsible for migrating that copy along with all its other state. This is how qemu_irq/gpio lines work. (2) the "clock" object does hold internal state, and it is owned by the source-end device, which is responsible for migrating that state. This is how ptimer objects work -- hw/core/ptimer.c defines a vmstate struct, but it is the devices that use a ptimer that put a VMSTATE_PTIMER entry in their vmstate structs to migrate the data. (3) the "clock" object can be a fully fledged device (ie a subclass of TYPE_DEVICE) which migrates its state entirely by itself. I don't have a firm view currently on which would be best here, but I guess I lean towards 2. 1 has the advantage of "just like qemu_irq" but the disadvantage that the destination end has no way to query the current clock value so has to manually track it itself. 3 is probably overkill here (and also makes it hard to retain migration backward compatibility when adding clock tree support to an existing machine model). > Concerning this frequency-reset port, we can obviously go back to the simple > frequency-only one if you think it is not a good idea. I don't really understand why reset is related here. Clock trees and reset domains don't sit in a 1-to-1 relationship, generally. Reset is a complicated and painful area and I think I would prefer to see a patchset which aimed to solve the clocktree modelling problem without dragging in the complexities of reset modelling. thanks -- PMM
