qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/11] Make memory_region_init_ram() and friends


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 00/11] Make memory_region_init_ram() and friends handle migration
Date: Fri, 14 Jul 2017 18:01:13 +0100

On 10 July 2017 at 11:05, Paolo Bonzini <address@hidden> wrote:
> On 07/07/2017 16:42, Peter Maydell wrote:
>> This patchset changes the memory region functions
>>  - memory_region_init_ram()
>>  - memory_region_init_rom()
>>  - memory_region_init_rom_device()
>> to all automatically register the backing memory they allocate
>> for migration using vmstate_register_ram(). Renamed functions
>>  - memory_region_init_ram_nomigrate()
>>  - memory_region_init_rom_nomigrate()
>>  - memory_region_init_rom_device_nomigrate()
>> are provided which only do the MR init, for the oddball
>> cases which want to manage migration of the backing memory
>> themselves (and to avoid behavioural changes for callers
>> which weren't managing correctly migration themselves...)
>>
>> The idea is based on discussion from a previous patchset:
>>  https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00764.html
>>
>> The series includes a largish coccinelle-scripted patch and a
>> few by-hand conversions which change callsites which previously
>> manually created the region and registered its backing ram in
>> two separate steps to use the new functions.
>>
>> This series does not include any patches to fix bugs like:
>>  * caller forgot to call vmstate_register_ram() so region
>>    is not actually migrated (eg hw/arm/highbank.c)
>>  * caller used vmstate_register_ram_global() even though it is
>>    a device, so you can't create 2 copies of the device (eg sm501)
>> because I wanted to stick to strictly no-behaviour-change
>> for this patch -- we can fix the bugs separately (fixes will
>> tend to imply migration compat breaks so can only be done
>> for some boards.) Most of the remaining callers of the
>> _nomigrate functions are buggy, I think (and a demonstration
>> that our current API does not score well on the "hard to
>> get wrong by accident" scale).
>
> Reviewed-by: Paolo Bonzini <address@hidden>

Thanks. I'm going to apply this directly to master (so then
I can check that nothing has got applied to it since which
uses the old semantics for these functions; nothing in
fact has.)

thanks
-- PMM



reply via email to

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