[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: |
Mon, 17 Jul 2017 10:01:34 +0100 |
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
- [Qemu-devel] [PATCH 04/11] memory: Rename memory_region_init_rom() and _rom_device() to _nomigrate(), (continued)
[Qemu-devel] [PATCH 07/11] hw: Use new memory_region_init_{ram, rom, rom_device}() functions, Peter Maydell, 2017/07/07
[Qemu-devel] [PATCH 03/11] memory: Rename memory_region_init_ram() to memory_region_init_ram_nomigrate(), Peter Maydell, 2017/07/07
Re: [Qemu-devel] [PATCH 00/11] Make memory_region_init_ram() and friends handle migration, Paolo Bonzini, 2017/07/10
Re: [Qemu-devel] [PATCH 00/11] Make memory_region_init_ram() and friends handle migration, Philippe Mathieu-Daudé, 2017/07/22