Re: [Qemu-devel] [PATCH 0/3] Add new utility function memory_region_allocate_aux_memory()

[Paolo Bonzini]

On 07/07/2017 12:43, Peter Maydell wrote:
> On 6 July 2017 at 18:47, Peter Maydell <address@hidden> wrote:
>> On 6 July 2017 at 18:26, Paolo Bonzini <address@hidden> wrote:
>>> Maybe, for memory_region_init_ram only, the owner argument can be made a
>>> DeviceState (or NULL)?
>>
>> Something that might influence things here -- of the twelve
>> callers of vmstate_register_ram(), only 6 use an 'owner'
>> pointer that's the same as the one they use for initializing
>> the memory region (and 3 of those are using _init_rom or
>> _init_rom_device rather than init_ram directly).
> 
> Conversely there are 14 or so places that init a RAM MR
> with a non-NULL owner but then use vmstate_register_ram_global
> rather than vmstate_register_ram, and so which would be
> stuck using the old _nomigrate() function if we make it
> use the owner pointer.

I think whenever feasible we should pay the price of breaking migration.
 I found these:

- aspeed_soc_realize

- integratorcm_init

- onenand_initfn (nseries)

- cg3_initfn (one init_ram in there is not using owner, might be changed
as well)

- sm501_init

- tcx_initfn

- milkymist_softusb_init

- milkymist_minimac2_init

- raven_realize

- idreg_init1

- afx_init1

- prom_init1 (two functions with the same name in two files)

- ram_realize

- lx60_net_init

The only problematic one for backwards compatibility is rom_set_mr.

> I guess we should think about the long term and design
> the API to encourage the behaviour we want for new code,
> rather than to catch as much of possible of existing
> usage, though?

Yes, though that leaves the possibility of people copying from the wrong
code, so if we can break migration compatibility that would be better in
the long term.

Paolo