On 04/25/2010 05:51 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 04/25/2010 05:29 PM, Jan Kiszka wrote:
There isn't. But I don't like hidden breakage.
It's (so far) an unproblematic API property we can document. I don't
like changing APIs just for "there might be the case that...".
I guess it's one of those agree to disagree things. I dislike known
broken APIs even if their none of their users are affected.
The API is not broken. I intentionally designed it for the single user
as I saw no need for more. If I oversaw something, I would really like
to learn about these cases.
The fact that the API assumes a single user is what's broken IMO.
If the API were to take a memory slot as parameter you could say it is
the responsibility of the slot's owner to multiplex (and since vga has a
single owner, no need to multiplex). But it takes a range.
kvm_set_migration_log() means, start logging now for all current and
future memory, until disabled.
Hmm, you mean plugging memory during ongoing migration is valid and can
be handled?
Sure (except that we don't have memory hotplug).
I'm a bit skeptical. What makes this different from, say,
PCI hotplugging which should be a no-go during migration as well?
PCI hotplugging should be handled in migration as well. Introducing
dependencies among unrelated features and expecting upper layers to
apply the correct constraints is unreasonable.
Currently we don't handle this, but we should. One way to do it is to
forward the hotplug/hotunplug along the migration channel.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
