On 6/15/20 4:45 PM, Gerd Hoffmann wrote: > 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.
Thanks you Gerd for the whole explanation. I added an entry to my TODO list to document this, based on your comment (and Corey's). I'll address it later, as you confirmed it doesn't impact this series. Regards, Phil.
