[Qemu-devel] New Memory API Question

[Qemu-devel] New Memory API Question

[John Baboval]

Sorry for coming late to the party on this... I only read qemu-devel 
through a filter so I missed all the discussions on the new memory API. 
I have a question as to how it works and how it's supposed to work in 
certain scenarios.

It's a question of flow. I'm following the code path through the 
creation of a new memory subregion. If I'm reading this properly, it 
would seem that a MemoryRegion - for example the ones used by VGA - go 
through the following flow:

memory_region_init_ram()   - (mr->destructor is set to 
memory_region_destructor_ram)
memory_region_add_subregion(system_memory, ...) ->
    memory_region_update_topology() ->
       address_space_update_topology()
          address_space_update_topology_part()
             as_memory_range_add()   - through the ops vector
                memory_region_prepare_ram_addr()


At this point it seems that the destructor is overwritten with the 
memory_region_destructor_iomem(), and it loses track of the proper way 
to ever free the memory region. Is this correct, or am I missing something?

Or does it not matter because nobody ever calls memory_region_destroy 
for system memory regions?

Thanks,
-John

Re: [Qemu-devel] New Memory API Question

[John Baboval]

So I've figured out the answer to my own question... I was, in fact, 
missing something.

The destructor for the subregion is not overwritten. It's the parent 
region's destructor that is written.

On 10/26/2011 09:52 AM, John Baboval wrote:
> Sorry for coming late to the party on this... I only read qemu-devel 
> through a filter so I missed all the discussions on the new memory 
> API. I have a question as to how it works and how it's supposed to 
> work in certain scenarios.
>
> It's a question of flow. I'm following the code path through the 
> creation of a new memory subregion. If I'm reading this properly, it 
> would seem that a MemoryRegion - for example the ones used by VGA - go 
> through the following flow:
>
> memory_region_init_ram()   - (mr->destructor is set to 
> memory_region_destructor_ram)
> memory_region_add_subregion(system_memory, ...) ->
>    memory_region_update_topology() ->
>       address_space_update_topology()
>          address_space_update_topology_part()
>             as_memory_range_add()   - through the ops vector
>                memory_region_prepare_ram_addr()
>
>
> At this point it seems that the destructor is overwritten with the 
> memory_region_destructor_iomem(), and it loses track of the proper way 
> to ever free the memory region. Is this correct, or am I missing 
> something?
>
> Or does it not matter because nobody ever calls memory_region_destroy 
> for system memory regions?
>
> Thanks,
> -John
>

Re: [Qemu-devel] New Memory API Question

[Avi Kivity]

On 10/26/2011 07:54 PM, John Baboval wrote:
> So I've figured out the answer to my own question... I was, in fact,
> missing something.
>
> The destructor for the subregion is not overwritten. It's the parent
> region's destructor that is written.

Why do you figure that?

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] New Memory API Question

[Avi Kivity]

On 10/26/2011 03:52 PM, John Baboval wrote:
> Sorry for coming late to the party on this... I only read qemu-devel
> through a filter so I missed all the discussions on the new memory
> API. I have a question as to how it works and how it's supposed to
> work in certain scenarios.
>
> It's a question of flow. I'm following the code path through the
> creation of a new memory subregion. If I'm reading this properly, it
> would seem that a MemoryRegion - for example the ones used by VGA - go
> through the following flow:
>
> memory_region_init_ram()   - (mr->destructor is set to
> memory_region_destructor_ram)
> memory_region_add_subregion(system_memory, ...) ->
>    memory_region_update_topology() ->
>       address_space_update_topology()
>          address_space_update_topology_part()
>             as_memory_range_add()   - through the ops vector
>                memory_region_prepare_ram_addr()
>
>
> At this point it seems that the destructor is overwritten with the
> memory_region_destructor_iomem(), and it loses track of the proper way
> to ever free the memory region. Is this correct, or am I missing
> something?

It's correct; this is a bug.

>
> Or does it not matter because nobody ever calls memory_region_destroy
> for system memory regions?

It can still happen via hotunplug of an ivshmem device, or memory
hotunplug (when it is eventually implemented).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.