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

[Jan Kiszka <jan.kiszka@web.de>]

[-- 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 --]