|
From: | Pierrick Bouvier |
Subject: | Re: [PATCH 9/9] contrib/plugins: add ips plugin example for cost modeling |
Date: | Wed, 19 Jun 2024 08:06:21 -0700 |
User-agent: | Mozilla Thunderbird |
On 6/19/24 02:49, Alex Bennée wrote:
Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:On 6/18/24 02:53, Alex Bennée wrote:Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:On 6/17/24 13:56, Dr. David Alan Gilbert wrote:* Pierrick Bouvier (pierrick.bouvier@linaro.org) wrote:On 6/14/24 15:00, Dr. David Alan Gilbert wrote:* Pierrick Bouvier (pierrick.bouvier@linaro.org) wrote:Hi Dave, On 6/12/24 14:02, Dr. David Alan Gilbert wrote:* Alex Bennée (alex.bennee@linaro.org) wrote:From: Pierrick Bouvier <pierrick.bouvier@linaro.org> 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?Oh yes - I can add that in the core plugin code.
Thanks!
[Prev in Thread] | Current Thread | [Next in Thread] |