qemu-devel
[Top][All Lists]
Advanced

[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: Thu, 6 Jul 2017 18:49:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

On 06/07/2017 18:26, Peter Maydell wrote:
> 
> I think that to avoid getting tangled up in trying to fix
> or deal with these handful of oddball cases at the same time
> as doing a global change to the easy cases, we should:
> 
>  * globally rename memory_region_init_ram to memory_region_init_ram_nomigrate
>    (and document that it is the caller's job to arrange to migrate the RAM)
>  * add new memory_region_init_ram which does memory_region_init_ram_nomigrate
>    + vmstate_register_ram
>  * coccinelle patch to switch to using that new function where possible
>  * get that lot committed, because it touches so many files and
>    is a recipe for conflicts
>  * look at the remaining handful of _nomigrate calls and perhaps
>    switch them where that would be a bug fix
> 
> Q: should we have _nomigrate versions of any of the other
> memory_region_init_ram* functions? I think it makes sense
> for only the basic _init_ram to do the migration for you,
> because that's the only case where the memory system is
> creating the backing storage for the caller, rather than the
> caller passing in the backing storage.

memory_region_init_ram_from_file theoretically would also fit this
description, but all of its callers would use the _nomigrate version.

Paolo

> "Be consistent for
> the full set of functions" would be the other obvious approach;
> I don't think I care too much either way.




reply via email to

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