Re: [PATCH v7 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument

[Philippe Mathieu-Daudé]

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.