[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/3] Add new utility function memory_region_allo
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 0/3] Add new utility function memory_region_allocate_aux_memory() |
Date: |
Fri, 7 Jul 2017 12:55:37 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 |
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