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: Mon, 15 Aug 2011 23:15:22 -0700 Message-ID: <4E4A0AFA.70409@redhat.com> References: <4E440131.6020200@redhat.com> <4E44CC1E.202@redhat.com> <20110815072648.GA2916@amt.cnet> <4E4929B8.2010509@redhat.com> <4E498116.9030800@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, quintela@redhat.com To: Umesh Deshpande Return-path: Received: from mail-gx0-f174.google.com ([209.85.161.174]:43726 "EHLO mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753658Ab1HPGP2 (ORCPT ); Tue, 16 Aug 2011 02:15:28 -0400 Received: by gxk21 with SMTP id 21so3618865gxk.19 for ; Mon, 15 Aug 2011 23:15:28 -0700 (PDT) In-Reply-To: <4E498116.9030800@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. :) Paolo