On Tue, Nov 27, 2018 at 18:20:25 +0000, Alex Bennée wrote: > > Emilio G. Cota <c...@braap.org> writes: > > > Signed-off-by: Emilio G. Cota <c...@braap.org> > > There are no users of this for now so I don't think this qualifies for a > first cut of the plugin API.
Fair enough. It was more as an example that plugins are not just for instrumentation purposes. Another example of this is the use of plugins to control the guest's clock -- for instance, there was this series https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg03028.html that implemented a module to control the guest's clock over sockets. Instead, a plugin can just be loaded to take control, and the plugin is free to interact with the outer world in whatever way it wants (sockets, pipes, etc.). So having a plugin infrastructure can make adding those features much easier to implement (FWIW, that patch never landed on master). > Is the lockstep support only their for > plugins? Is there any practical use that isn't handled by non-MTTCG > round-robin and icount type scenarios? This is a compromise between icount and MTTCG by limiting the latter's skew among vCPUs. So you don't get full determinism, but get closer to it without giving up parallelism. I think this feature could be added without plugins, by for instance defaulting to an "MTTCG icount-like" behaviour. That is, the time window of each CPU would expire after N instructions executed. But I didn't have a use case for that; my use case is to control the time windows from the plugins, since in my simulator the plugin controls the guest clock, and instructions have different latencies. So yes, feel free to skip this patch! Thanks, Emilio
