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 07:10:12 -0700 Message-ID: <4E4928C4.4020104@redhat.com> References: <4E440131.6020200@redhat.com> <4E44CC1E.202@redhat.com> <4E48C078.50109@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, quintela@redhat.com, mtosatti@redhat.com To: Umesh Deshpande Return-path: Received: from mail-pz0-f42.google.com ([209.85.210.42]:60054 "EHLO mail-pz0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753607Ab1HOOKW (ORCPT ); Mon, 15 Aug 2011 10:10:22 -0400 Received: by pzk37 with SMTP id 37so2952627pzk.1 for ; Mon, 15 Aug 2011 07:10:22 -0700 (PDT) In-Reply-To: <4E48C078.50109@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/14/2011 11:45 PM, Umesh Deshpande wrote: >> That's not too good because qemu_get_ram_ptr is a hot path for TCG. > > Looks like qemu_get_ram_ptr isn't called from the source side code of > guest migration. Right, but since you are accessing the list from both migration and non-migration threads, qemu_get_ram_ptr needs to take the ram_list lock. The ram_list and IO thread mutexes together protect the "next" member, and you need to hold them both when modifying the list. See the reply to Marcelo for a proposed solution. Paolo