From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBTGL-0002PJ-AM for qemu-devel@nongnu.org; Mon, 19 Aug 2013 13:29:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBTGC-0004l5-Qt for qemu-devel@nongnu.org; Mon, 19 Aug 2013 13:29:05 -0400 Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:34933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBTGC-0004kw-K8 for qemu-devel@nongnu.org; Mon, 19 Aug 2013 13:28:56 -0400 Received: by mail-wg0-f47.google.com with SMTP id j13so3814249wgh.14 for ; Mon, 19 Aug 2013 10:28:55 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <521255AC.2080404@redhat.com> Date: Mon, 19 Aug 2013 19:28:12 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1376922370-5681-1-git-send-email-mst@redhat.com> <1376922370-5681-3-git-send-email-mst@redhat.com> In-Reply-To: <1376922370-5681-3-git-send-email-mst@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 2/2] loader: store FW CFG ROM files in RAM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Peter Maydell , Anthony Liguori , lersek@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com Il 19/08/2013 16:26, Michael S. Tsirkin ha scritto: > ROM files that are put in FW CFG are copied to guest ram, by BIOS, but > they are not backed by RAM so they don't get migrated. > > Each time we change two bytes in such a ROM this breaks cross-version > migration: since we can migrate after BIOS has read the first byte but > before it has read the second one, getting an inconsistent state. > > Future-proof this by creating, for each such ROM, > an MR serving as the backing store. > This MR is never mapped into guest memory, but it's registered > as RAM so it's migrated with the guest. > > Naturally, this only helps for -M 1.7 and up, older machine types > will still have the cross-version migration bug. > Luckily the race window for the problem to trigger is very small, > which is also likely why we didn't notice the cross-version > migration bug in testing yet. > > Signed-off-by: Michael S. Tsirkin This doesn't really help much unless we support migration of different-sized RAM regions, does it? In particular, what happens if the region is smaller on the destination? Do we get garbage written out of a malloc-ed region's bounds? The patches look good, but I'm not sure they are an improvement yet. Paolo