Hi, > > I can explain the rationale for that change, but I'm not sure of the > > answer to your question. That changes makes sure that the fw_cfg data > > remains exactly the same even on newer versions of qemu if the machine > > is set the same. This way you can do migrations to newer qemu versions > > and anything using fw_cfg won't get confused because the data changes. > > > > The reason that change was so complex was preserving the order for > > migrating from older versions. > > > > This is only about migration. I'm not sure what gen_id is, but if it's > > migrated, it better be future proof. > > Whenever introducing a new fw_cfg file (*any* new named file), how do we > decide whether we need fw_cfg_set_order_override()?
The whole point of the sorting is to make sure the fw_cfg directory listing entry (FW_CFG_FILE_DIR) is stable and doesn't change underneath the guest when it gets live-migrated. That sorting was added in qemu 2.6, to make sure things don't chance by accident in case the initialization order changes. Now you've got a problem when you migrate from qemu 2.5 (+older) to qemu 2.6 (+newer), because 2.5 has the entries in initialization order and 2.6 has the entries in alphabetical order. To deal with that machine types for 2.5 & older keep the old sort order. This is the reason why legacy_fw_cfg_order exists. For new features and files you can completely ignore the whole legacy sorting mess. cross-version live migration works only for features supported by both qemu versions, therefore the legacy sorting is only relevant for features & files already supported by qemu 2.5. HTH, Gerd
