[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] fw cfg files cross-version migration races
From: |
Gabriel L. Somlo |
Subject: |
Re: [Qemu-devel] fw cfg files cross-version migration races |
Date: |
Mon, 1 Jun 2015 14:00:22 -0400 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Mon, Jun 01, 2015 at 05:44:47PM +0200, Michael S. Tsirkin wrote:
> > > 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.
Oh, you mean here:
typedef struct FWCfgEntry {
uint32_t len;
uint8_t *data;
void *callback_opaque;
FWCfgReadCallback read_callback;
} FWCfgEntry;
... I can't just assume that 'read_callback' is a valid function
pointer in the context of the destination host ?
Ouch, that could get painful really really quickly :)
Thanks,
--Gabriel
- [Qemu-devel] fw cfg files cross-version migration races, Michael S. Tsirkin, 2015/06/01
- Re: [Qemu-devel] fw cfg files cross-version migration races, Daniel P. Berrange, 2015/06/01
- Re: [Qemu-devel] fw cfg files cross-version migration races, Gabriel L. Somlo, 2015/06/01
- Re: [Qemu-devel] fw cfg files cross-version migration races, Michael S. Tsirkin, 2015/06/01
- Re: [Qemu-devel] fw cfg files cross-version migration races,
Gabriel L. Somlo <=
- Re: [Qemu-devel] fw cfg files cross-version migration races, Gabriel L. Somlo, 2015/06/01
- Re: [Qemu-devel] fw cfg files cross-version migration races, Laszlo Ersek, 2015/06/02
- Re: [Qemu-devel] fw cfg files cross-version migration races, Gerd Hoffmann, 2015/06/02
- Re: [Qemu-devel] fw cfg files cross-version migration races, Paolo Bonzini, 2015/06/03
- Re: [Qemu-devel] fw cfg files cross-version migration races, Michael S. Tsirkin, 2015/06/03
- Re: [Qemu-devel] fw cfg files cross-version migration races, Gabriel L. Somlo, 2015/06/05
- Re: [Qemu-devel] fw cfg files cross-version migration races, Gerd Hoffmann, 2015/06/08
- Re: [Qemu-devel] fw cfg files cross-version migration races, Michael S. Tsirkin, 2015/06/08
- Re: [Qemu-devel] fw cfg files cross-version migration races, Gerd Hoffmann, 2015/06/08
- Re: [Qemu-devel] fw cfg files cross-version migration races, Paolo Bonzini, 2015/06/08