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

Jan Kiszka
2010-04-25T14:51:59Z

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

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.
>

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]