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

[Avi Kivity <avi@redhat.com>]

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