On 6/18/24 02:53, Alex Bennée wrote:
Pierrick Bouvier <pierrick.bouvier@xxxxxxxxxx> writes:
On 6/17/24 13:56, Dr. David Alan Gilbert wrote:
* Pierrick Bouvier (pierrick.bouvier@xxxxxxxxxx) wrote:
On 6/14/24 15:00, Dr. David Alan Gilbert wrote:
* Pierrick Bouvier (pierrick.bouvier@xxxxxxxxxx) wrote:
Hi Dave,
On 6/12/24 14:02, Dr. David Alan Gilbert wrote:
* Alex Bennée (alex.bennee@xxxxxxxxxx) wrote:
From: Pierrick Bouvier <pierrick.bouvier@xxxxxxxxxx>
This plugin uses the new time control interface to make decisions
about the state of time during the emulation. The algorithm is
currently very simple. The user specifies an ips rate which applies
per core. If the core runs ahead of its allocated execution time the
plugin sleeps for a bit to let real time catch up. Either way time is
updated for the emulation as a function of total executed instructions
with some adjustments for cores that idle.
A few random thoughts:
a) Are there any definitions of what a plugin that controls time
should do with a live migration?
It's not something that was considered as part of this work.
That's OK, the only thing is we need to stop anyone from hitting problems
when they don't realise it's not been addressed.
One way might be to add a migration blocker; see include/migration/blocker.h
then you might print something like 'Migration not available due to plugin ....'
So basically, we could make a call to migrate_add_blocker(), when someone
request time_control through plugin API?
IMHO, it's something that should be part of plugin API (if any plugin calls
qemu_plugin_request_time_control()), instead of the plugin code itself. This
way, any plugin getting time control automatically blocks any potential
migration.
Note my question asked for a 'any definitions of what a plugin ..' -
so
you could define it that way, another one is to think that in the future
you may allow it and the plugin somehow interacts with migration not to
change time at certain migration phases.
I would be in favor to forbid usage for now in this context. I'm not
sure why people would play with migration and plugins generally at
this time (there might be experiments or use cases I'm not aware of),
so a simple barrier preventing that seems ok.
This plugin is part of an experiment where we implement a qemu feature
(icount=auto in this case) by using plugins. If it turns into a
successful usage and this plugin becomes popular, we can always lift
the limitation later.
@Alex, would you like to add this now (icount=auto is still not
removed from qemu), or wait for integration, and add this as another
patch?
I think we follow the deprecation process so once integrated we post a
deprecation notice in:
https://qemu.readthedocs.io/en/master/about/deprecated.html
and then remove it after a couple of releases.
Sorry, I was not clear. I meant do we add a blocker in case someone
tries to migrate a vm while this plugin is used?
