From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [uq/master patch 2/5] kvm: add logging count to slots Date: Sun, 25 Apr 2010 17:58:53 +0300 Message-ID: <4BD458AD.9020500@redhat.com> References: <20100423170410.914857113@amt.cnet> <20100423170645.675040544@amt.cnet> <4BD29F22.8020806@web.de> <4BD4367F.5060307@redhat.com> <4BD44A4D.4060008@web.de> <4BD44F13.3070000@redhat.com> <4BD451D9.4090209@web.de> <4BD4547C.5060907@redhat.com> <4BD45709.9070705@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:63706 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752779Ab0DYO6z (ORCPT ); Sun, 25 Apr 2010 10:58:55 -0400 In-Reply-To: <4BD45709.9070705@web.de> Sender: kvm-owner@vger.kernel.org List-ID: 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