[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v7 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argume
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH v7 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument |
Date: |
Mon, 15 Jun 2020 17:02:13 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
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.