[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [uq/master patch 2/5] kvm: add logging count to slots

From: Jan Kiszka
Subject: [Qemu-devel] Re: [uq/master patch 2/5] kvm: add logging count to slots
Date: Sun, 25 Apr 2010 16:51:53 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

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 logging API is consistently converted, not just extended
>>>>      (IOW, migration_log is converted to logging_count)
>>> migration_log needs to remain global, since we want hotplug memory to
>>> autostart logging.
>> Can't follow yet, what will be the usage pattern of
>> kvm_set_migration_log? Or would the hotplug code require a separate
>> interface? Is it already the multi-client use case I'm looking for?
> 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? I'm a bit skeptical. What makes this different from, say,
PCI hotplugging which should be a no-go during migration as well?

> It could be implemented in terms of kvm_log_start() (which would provide
> a multi-client use case), but it isn't now.
> I guess it is a logical example of how two clients can exist, even
> though they don't step on each others toes in practice since their
> enable flags are kept separate by the implementation.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]