On 24/02/2017 11:48, Dr. David Alan Gilbert wrote:
> * Laurent Vivier (lviv...@redhat.com) wrote:
>> On 06/02/2017 18:32, Dr. David Alan Gilbert (git) wrote:
>>> From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
>>>
>>> When using postcopy with hugepages, we require the source
>>> and destination page sizes for any RAMBlock to match; note
>>> that different RAMBlocks in the same VM can have different
>>> page sizes.
>>>
>>> Transmit them as part of the RAM information header and
>>> fail if there's a difference.
>>>
>>> Signed-off-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
>>> ---
>>> migration/ram.c | 17 +++++++++++++++++
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/migration/ram.c b/migration/ram.c
>>> index b405e4a..5726563 100644
>>> --- a/migration/ram.c
>>> +++ b/migration/ram.c
>>> @@ -1979,6 +1979,9 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
>>> qemu_put_byte(f, strlen(block->idstr));
>>> qemu_put_buffer(f, (uint8_t *)block->idstr, strlen(block->idstr));
>>> qemu_put_be64(f, block->used_length);
>>> + if (migrate_postcopy_ram() && block->page_size !=
>>> qemu_host_page_size) {
>>> + qemu_put_be64(f, block->page_size);
>>> + }
>>
>> I understand we don't break migration to previous machine type by adding
>> data in the migration stream because migration is already broken when
>> block->page_size != qemu_host_page_size. Am I correct?
>
> Right, the previous patch - the one with the summary word - should have failed
> the migration before we get to this point.
>
> This patch can detect a more subtle problem - e.g. we still have huge pages
> used
> by some of the RAM Blocks, but not all the same ones as the source.
Thanks.
Reviewed-by: Laurent Vivier <lviv...@redhat.com>
Laurent
