[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback

From: David Hildenbrand
Subject: Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback
Date: Wed, 5 Feb 2020 17:40:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1

>> Oh, and one more reason why the proposal in this patch is inconsistent:
>> When migrating resizable memory regions (RAM_SAVE_FLAG_MEM_SIZE) we
>> store the block->used_length (ram_save_setup()) and use that value to
>> resize the region on the target (ram_load_precopy() -> qemu_ram_resize()).
>> This will be the value the callback will be called with. Page aligned.
> Sorry, I didn’t quite get that point and not sure how "req_length" approach 
> will affect the migration.

The issue is that on migration, you will lose the sub-page size either
way. So your callback will be called
- on the migration source with a sub-page size (via
  memory_region_ram_resize() from e.g., hw/i386/acpi-build.c)
- on the migration target with a page-aligned size (via
  qemu_ram_resize() from migration/ram.c)

So this is inconsistent, especially when migrating.

Is there a way to get access to the sub-page size without passing it
through the callback?

Like in fw_cfg_modify_file() do some fancy lookup and use the sub-page
size instead of the passed size? (might have to be stored somewhere and
refetched - and migrated)


David / dhildenb

reply via email to

[Prev in Thread] Current Thread [Next in Thread]