qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC 2/8] numa: call ->ram_block_removed() in ram_block_notifer_remo


From: David Hildenbrand
Subject: Re: [RFC 2/8] numa: call ->ram_block_removed() in ram_block_notifer_remove()
Date: Wed, 30 Mar 2022 10:42:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2

On 23.03.22 12:17, Stefan Hajnoczi wrote:
> When a RAMBlockNotifier is added, ->ram_block_added() is called with all
> existing RAMBlocks. There is no equivalent ->ram_block_removed() call
> when a RAMBlockNotifier is removed.
> 
> The util/vfio-helpers.c code (the sole user of RAMBlockNotifier) is fine
> with this asymmetry because it does not rely on RAMBlockNotifier for
> cleanup. It walks its internal list of DMA mappings and unmaps them by
> itself.
> 
> Future users of RAMBlockNotifier may not have an internal data structure
> that records added RAMBlocks so they will need ->ram_block_removed()
> callbacks.
> 
> This patch makes ram_block_notifier_remove() symmetric with respect to
> callbacks. Now util/vfio-helpers.c needs to unmap remaining DMA mappings
> after ram_block_notifier_remove() has been called. This is necessary
> since users like block/nvme.c may create additional DMA mappings that do
> not originate from the RAMBlockNotifier.
> 
> Cc: David Hildenbrand <david@redhat.com>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Reviewed-by: David Hildenbrand <david@redhat.com>


-- 
Thanks,

David / dhildenb




reply via email to

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