From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBTbp-0004R0-JT for qemu-devel@nongnu.org; Mon, 19 Aug 2013 13:51:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBTbi-0004Lf-JT for qemu-devel@nongnu.org; Mon, 19 Aug 2013 13:51:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBTbi-0004LR-Aq for qemu-devel@nongnu.org; Mon, 19 Aug 2013 13:51:10 -0400 Message-ID: <52125ADF.80802@redhat.com> Date: Mon, 19 Aug 2013 19:50:23 +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> <521255AC.2080404@redhat.com> <20130819174010.GA7737@redhat.com> In-Reply-To: <20130819174010.GA7737@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 19:40, Michael S. Tsirkin ha scritto: > On Mon, Aug 19, 2013 at 07:28:12PM +0200, Paolo Bonzini wrote: >> 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? > > It does because RAM blocks are multiples of target pages, so the size > won't change all that much. This is more or less similar to what happens > e.g. with BIOS (aligned to power of two). > It worked for BIOS for a while. Yeah, it should work. On one hand there are many different files, so many different points of failures. On the other hand most of the files are small, so the almost-4 KiB legroom is not bad. > No, migration fails if block size does not match. Good. > Well they protect us against minor changes which are > IMO more likely than major changes. > > We can add code to allow ram block size changes on top. > I'm not sure it's a requirement right now. No, it's not---thanks for the clarifications. Paolo