From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [RFC PATCH v3 3/4] lock to protect memslots Date: Tue, 16 Aug 2011 00:56:14 -0700 Message-ID: <4E4A229E.2040209@redhat.com> References: <4E440131.6020200@redhat.com> <4E44CC1E.202@redhat.com> <20110815072648.GA2916@amt.cnet> <4E4929B8.2010509@redhat.com> <4E498116.9030800@redhat.com> <4E4A0AFA.70409@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Umesh Deshpande , Marcelo Tosatti , kvm@vger.kernel.org, quintela@redhat.com, Kevin Wolf To: unlisted-recipients:; (no To-header on input) Return-path: Received: from mail-yx0-f174.google.com ([209.85.213.174]:38348 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750869Ab1HPH4T (ORCPT ); Tue, 16 Aug 2011 03:56:19 -0400 Received: by yxj19 with SMTP id 19so3601338yxj.19 for ; Tue, 16 Aug 2011 00:56:18 -0700 (PDT) In-Reply-To: <4E4A0AFA.70409@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/15/2011 11:15 PM, Paolo Bonzini wrote: > On 08/15/2011 01:27 PM, Umesh Deshpande wrote: >> Yes, the mru list patch would obviate the need of holding the ram_list >> mutex in qemu_get_ram_ptr. > > Feel free to take it and complete it with locking then! > >> Also, I was planning to protect the whole migration thread with iothread >> mutex, and ram_list mutex. (i.e. holding ram_list mutex while sleeping >> between two iterations, when we release iothread mutex). This will >> prevent the memslot block removal altogether during the migration. Do >> you see any problem with this? > > No, indeed holding the ram_list mutex through all the migration "fixes" > the problems with ram_lists removing during migration. I guess whoever > will implement memory hotplug, will find a way around it. :) BTW, now that I think of it, do you have ideas on how to do the migration thread do block migration? Paolo