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

[Peter Maydell]

On 14 July 2017 at 18:01, Peter Maydell <address@hidden> wrote:
> 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.)

...now applied (with the minor comment fixes requested).

thanks
-- PMM