From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1rNb-0000k0-5v for qemu-devel@nongnu.org; Mon, 08 Jun 2015 03:21:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z1rNW-00026u-4x for qemu-devel@nongnu.org; Mon, 08 Jun 2015 03:21:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1rNV-00026d-Vx for qemu-devel@nongnu.org; Mon, 08 Jun 2015 03:21:50 -0400 Message-ID: <1433748105.5046.6.camel@redhat.com> From: Gerd Hoffmann Date: Mon, 08 Jun 2015 09:21:45 +0200 In-Reply-To: <20150605160555.GH9951@HEDWIG.INI.CMU.EDU> References: <20150601141054.GA11304@redhat.com> <20150601141343.GH13155@redhat.com> <20150601153237.GE2120@HEDWIG.INI.CMU.EDU> <20150601174409-mutt-send-email-mst@redhat.com> <20150601180022.GI2120@HEDWIG.INI.CMU.EDU> <20150601203126.GK2120@HEDWIG.INI.CMU.EDU> <1433229074.1637.7.camel@nilsson.home.kraxel.org> <20150605160555.GH9951@HEDWIG.INI.CMU.EDU> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] fw cfg files cross-version migration races List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: pbonzini@redhat.com, lersek@redhat.com, qemu-devel@nongnu.org, mst@redhat.com Hi, > > So, sorting entries (and the index assigned too) should fix this, right? > > That looks easiest to me. > > Presumably, anything happening before (and after) user-provided blobs > are inserted will continue happening in the same order everywhere. Which might change in the future though, in case the initialization order changes for some reason. It's not a problem we have at the moment, so this stuff isn't urgent. But we might face it in the future. > So we really only have to sort the user provided blobs, so that if > the same *set* is provided on both ends of the migration, things would > work out OK. I would simply sort everything (and do it for new machine types only, for backward compatibility reasons). Sorting user-provided blobs only adds complexity for no reason. > If a *different* set of blobs is specified on the migration origin vs. > the migration destination, we lose by default and worrying about it is > pointless -- did I get that right ? Yes. For migration to succeed you have to supply the same configuration on both ends. That includes user-provided fw_cfg blobs of course. cheers, Gerd