From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56141) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzRtW-0006ha-4K for qemu-devel@nongnu.org; Mon, 01 Jun 2015 11:44:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzRtS-0002Zj-Te for qemu-devel@nongnu.org; Mon, 01 Jun 2015 11:44:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzRtS-0002Ze-Oy for qemu-devel@nongnu.org; Mon, 01 Jun 2015 11:44:50 -0400 Date: Mon, 1 Jun 2015 17:44:47 +0200 From: "Michael S. Tsirkin" Message-ID: <20150601174409-mutt-send-email-mst@redhat.com> References: <20150601141054.GA11304@redhat.com> <20150601141343.GH13155@redhat.com> <20150601153237.GE2120@HEDWIG.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150601153237.GE2120@HEDWIG.INI.CMU.EDU> 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: kraxel@redhat.com, qemu-devel@nongnu.org On Mon, Jun 01, 2015 at 11:32:37AM -0400, Gabriel L. Somlo wrote: > On Mon, Jun 01, 2015 at 03:13:43PM +0100, Daniel P. Berrange wrote: > > On Mon, Jun 01, 2015 at 04:10:54PM +0200, Michael S. Tsirkin wrote: > > > Hi all, > > > At the moment we have devices adding and removing fw cfg file entries. > > > One problem is that this makes the contents of fw cfg > > > depend on order of device initialization. > > > Since the fw cfg file list is not migrated, this means that > > > guest will break if it is migrated between qemu versions > > > which generate the list diferently, and if migration triggers > > > while guest happens to read fw cfg. > > > > > > As there are plans to extend the use of fw cfg, I think it's > > > important to fix this issue sooner rather than later. > > > > > > Ideas: > > > - sort fw cfg files by name before exposing them to guest > > > - keep doing what we did for compat machine types, > > > hope that things don't break too often > > > > > > More ideas? Comments? Anyone wants to try implementing this? > > > > Shouldn't we migrate the fw cfg data that the source host generates > > originally, rather than trying to play games make sure the way it > > is re-generated on dest doesn't change. > > Right now, in hw/nvram/fw_cfg.c, we have: > > struct FWCfgState { > /*< private >*/ > SysBusDevice parent_obj; > /*< public >*/ > > FWCfgEntry entries[2][FW_CFG_MAX_ENTRY]; > FWCfgFiles *files; > uint16_t cur_entry; > uint32_t cur_offset; > Notifier machine_ready; > }; > > and, later: > > static const VMStateDescription vmstate_fw_cfg = { > .name = "fw_cfg", > .version_id = 2, > .minimum_version_id = 1, > .fields = (VMStateField[]) { > VMSTATE_UINT16(cur_entry, FWCfgState), > VMSTATE_UINT16_HACK(cur_offset, FWCfgState, is_version_1), > VMSTATE_UINT32_V(cur_offset, FWCfgState, 2), > VMSTATE_END_OF_LIST() > } > }; > > Would this be as simple as adding a VMSTATE_ARRAY* for 'entries' > and something like a VMSTATE_VBUFFER_ALLOC_UINT32 for 'files', which > is dynamically allocated the first time a fwcfg "file" is inserted ? > > The one catch is that the value of the "files" pointer is itself a > fw_cfg entry (FW_CFG_FILE_DIR), so that would need to be "patched" > on the destination side... > > I do like the idea of simply migrating the full content of the fw_cfg > device though, seems like the safest solution. > > Thanks much, > --Gabriel OK but you need to do a bunch of work on load, e.g. some fw cfg entries trigger callbacks on access, etc.