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: Fri, 12 Aug 2011 08:45:50 +0200 Message-ID: <4E44CC1E.202@redhat.com> References: <4E440131.6020200@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Umesh Deshpande , kvm@vger.kernel.org, quintela@redhat.com, mtosatti@redhat.com To: unlisted-recipients:; (no To-header on input) Return-path: Received: from mail-qw0-f46.google.com ([209.85.216.46]:57392 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751189Ab1HLGpy (ORCPT ); Fri, 12 Aug 2011 02:45:54 -0400 Received: by qwk3 with SMTP id 3so1416018qwk.19 for ; Thu, 11 Aug 2011 23:45:54 -0700 (PDT) In-Reply-To: <4E440131.6020200@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/11/2011 06:20 PM, Paolo Bonzini wrote: >> >> + qemu_mutex_lock_ramlist(); >> QLIST_REMOVE(block, next); >> QLIST_INSERT_HEAD(&ram_list.blocks, block, next); >> + qemu_mutex_unlock_ramlist(); > > Theoretically qemu_get_ram_ptr should be protected. The problem is not > just accessing the ramlist, it is accessing the data underneath it > before anyone frees it. Luckily we can set aside that problem for now, > because qemu_ram_free_from_ptr is only used by device assignment and > device assignment makes VMs unmigratable. Hmm, rethinking about it, all the loops in exec.c should be protected from the mutex. That's not too good because qemu_get_ram_ptr is a hot path for TCG. Perhaps you can also avoid the mutex entirely, and just disable the above optimization for most-recently-used-block while migration is running. It's not a complete solution, but it could be good enough until we have RAM hot-plug/hot-unplug. Paolo