qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v7 6/6] hostmem: Handle remapping of RAM


From: David Hildenbrand
Subject: Re: [PATCH v7 6/6] hostmem: Handle remapping of RAM
Date: Tue, 4 Feb 2025 19:55:52 +0100
User-agent: Mozilla Thunderbird

On 04.02.25 18:58, Peter Xu wrote:
On Tue, Feb 04, 2025 at 06:50:17PM +0100, David Hildenbrand wrote:
       /*
@@ -595,6 +628,7 @@ static const TypeInfo host_memory_backend_info = {
       .instance_size = sizeof(HostMemoryBackend),
       .instance_init = host_memory_backend_init,
       .instance_post_init = host_memory_backend_post_init,
+    .instance_finalize = host_memory_backend_finalize,
       .interfaces = (InterfaceInfo[]) {
           { TYPE_USER_CREATABLE },
           { }
diff --git a/include/system/hostmem.h b/include/system/hostmem.h
index 5c21ca55c0..170849e8a4 100644
--- a/include/system/hostmem.h
+++ b/include/system/hostmem.h
@@ -83,6 +83,7 @@ struct HostMemoryBackend {
       HostMemPolicy policy;
       MemoryRegion mr;
+    RAMBlockNotifier ram_notifier;
   };

Thinking about Peters comment, it would be a nice improvement to have a
single global memory-backend notifier that looks up the fitting memory
backend, instead of having one per memory backend.

Yes, this could also avoid O(N**2).

Ah, and now I remember where these 3 patches originate from: virtio-mem handling.

For virtio-mem I want to register also a remap handler, for example, to perform the custom preallocation handling.

So there will be at least two instances getting notified (memory backend, virtio-mem), and the per-ramblock one would have only allowed to trigger one (at least with a simple callback as we have today for ->resize).

--
Cheers,

David / dhildenb




reply via email to

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