On Thu, Apr 11, 2019 at 01:46:27PM +0200, Igor Mammedov wrote: >On Thu, 11 Apr 2019 09:32:11 +0800 >Wei Yang <richardw.y...@linux.intel.com> wrote: >
[...] >> To be honest, this is what I feel confused in your previous reply. >> >> First I want to confirm both fields in RAMBlock affects the migration: >> >> * used_length >> * max_length >> >> Both of them should be the same on both source/destination, otherwise the >> migration would fail. >well, it works fine for me. >Where do you see max_length being used during migration? > I asked my colleague, but seems you are right. > >> Then I thought the migration would be broken if source/destination has >> different knowledge about acpi table size. Because this will introduce >> different value of used_length, even we have resizable MemoryRegion. >> >> The 1st time ACPI generation flow: >> >> acpi_add_rom_blob >> rom_add_blob >> rom_set_mr >> memory_region_init_resizable_ram >> qemu_ram_alloc_resizable >> new_block->used_length = size >> new_block->max_length = max_size >> >> The 2nd time ACPI generation flow: >> >> acpi_ram_update >> memory_regioin_ram_resize >> qemu_ram_resize >> block->used_length = new_size >> >> The max_length is always the same, while used_length would be changed to the >> actual table_blob size. >> >> In case source/destination has different knowledge about acpi table size, the >> table_blob size(even after aligned) could be different. >> >> This is why I thought there is still some chance to break migration after >> resizable MemoryRegion. >> >> Do I miss something? >yes, you did, max_length does not influence migration stream. >see what above mentioned commits and ram_load() -> "if (length != >block->used_length)" do. > I see this in the code. So the destination will check length and adjust self's length if it doesn't equal to the source. Thanks :-) -- Wei Yang Help you, Help me