From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O63IR-0003o1-7t for qemu-devel@nongnu.org; Sun, 25 Apr 2010 10:58:59 -0400 Received: from [140.186.70.92] (port=39326 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O63IP-0003nC-HC for qemu-devel@nongnu.org; Sun, 25 Apr 2010 10:58:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O63IN-0002hI-T8 for qemu-devel@nongnu.org; Sun, 25 Apr 2010 10:58:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61636) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O63IN-0002h9-J2 for qemu-devel@nongnu.org; Sun, 25 Apr 2010 10:58:55 -0400 Message-ID: <4BD458AD.9020500@redhat.com> Date: Sun, 25 Apr 2010 17:58:53 +0300 From: Avi Kivity MIME-Version: 1.0 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> In-Reply-To: <4BD45709.9070705@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [uq/master patch 2/5] kvm: add logging count to slots List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org 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