Il 02/10/2014 15:49, Michael S. Tsirkin ha scritto: >>> The issue is that incoming migration might have a different >>> fw_cfg size from what we have. >> >> Understood now. >> >>> I think migrating this value will solve the issue in a cleaner way. >> >> Perhaps. The question is whether it would complicate the >> forwards-migration code beyond what is sane. I think we are practically >> speaking stuck with RAM. > > Migrating RAM size is actually useful too, I think someone asked for it.
Migrating RAM size was discussed for BIOS and option ROMs, in order to support migration from old versions of QEMU. It was floated around for some time, but ultimately we ended up shipping two copies of affected firmware (128k/256k BIOS, and non-EFI/EFI option ROMs). For BIOS it wouldn't be enough, because the BIOS size affects the memory map. Of course ACPI tables aren't mapped anywhere, but I'd be wary of adding code to migration that is half-broken and almost never used. Also, RAM blocks that have different size would be yet another thing that makes machine types "almost compatible" with the QEMU version they're supposed to represent. In a scenario similar to John's, with mutable RAM sizes, would have likely broken all machine types, because we would not have bothered doing full backwards-compatibility. I'm not an advocate of backwards bug-compatibility, but I think RAM block sizes are way beyond the line of what we should be allowed to modify between machine types. Paolo
