From: David Hildenbrand <david@redhat.com>
To: "Chenyi Qiang" <chenyi.qiang@intel.com>,
"Alexey Kardashevskiy" <aik@amd.com>,
"Peter Xu" <peterx@redhat.com>,
"Gupta Pankaj" <pankaj.gupta@amd.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Michael Roth" <michael.roth@amd.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org,
Williams Dan J <dan.j.williams@intel.com>,
Peng Chao P <chao.p.peng@intel.com>,
Gao Chao <chao.gao@intel.com>, Xu Yilun <yilun.xu@intel.com>,
Li Xiaoyao <xiaoyao.li@intel.com>
Subject: Re: [PATCH v4 03/13] memory: Unify the definiton of ReplayRamPopulate() and ReplayRamDiscard()
Date: Fri, 25 Apr 2025 14:42:12 +0200 [thread overview]
Message-ID: <37cace3c-942e-457d-8a1a-fa37050428a7@redhat.com> (raw)
In-Reply-To: <20250407074939.18657-4-chenyi.qiang@intel.com>
On 07.04.25 09:49, Chenyi Qiang wrote:
> Update ReplayRamDiscard() function to return the result and unify the
> ReplayRamPopulate() and ReplayRamDiscard() to ReplayStateChange() at
> the same time due to their identical definitions. This unification
> simplifies related structures, such as VirtIOMEMReplayData, which makes
> it more cleaner and maintainable.
>
> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
> ---
> Changes in v4:
> - Modify the commit message. We won't use Replay() operation when
> doing the attribute change like v3.
>
> Changes in v3:
> - Newly added.
> ---
[...]
>
> -typedef int (*ReplayRamPopulate)(MemoryRegionSection *section, void *opaque);
> -typedef void (*ReplayRamDiscard)(MemoryRegionSection *section, void *opaque);
> +typedef int (*ReplayStateChange)(MemoryRegionSection *section, void *opaque);
>
But it's not a state change.
ReplayRamState maybe?
[...]
> /*
> diff --git a/system/memory.c b/system/memory.c
> index 62d6b410f0..b5ab729e13 100644
> --- a/system/memory.c
> +++ b/system/memory.c
> @@ -2147,7 +2147,7 @@ bool ram_discard_manager_is_populated(const RamDiscardManager *rdm,
>
> int ram_discard_manager_replay_populated(const RamDiscardManager *rdm,
> MemoryRegionSection *section,
> - ReplayRamPopulate replay_fn,
> + ReplayStateChange replay_fn,
> void *opaque)
> {
> RamDiscardManagerClass *rdmc = RAM_DISCARD_MANAGER_GET_CLASS(rdm);
> @@ -2156,15 +2156,15 @@ int ram_discard_manager_replay_populated(const RamDiscardManager *rdm,
> return rdmc->replay_populated(rdm, section, replay_fn, opaque);
> }
>
> -void ram_discard_manager_replay_discarded(const RamDiscardManager *rdm,
> - MemoryRegionSection *section,
> - ReplayRamDiscard replay_fn,
> - void *opaque)
> +int ram_discard_manager_replay_discarded(const RamDiscardManager *rdm,
> + MemoryRegionSection *section,
> + ReplayStateChange replay_fn,
> + void *opaque)
> {
> RamDiscardManagerClass *rdmc = RAM_DISCARD_MANAGER_GET_CLASS(rdm);
>
> g_assert(rdmc->replay_discarded);
> - rdmc->replay_discarded(rdm, section, replay_fn, opaque);
> + return rdmc->replay_discarded(rdm, section, replay_fn, opaque);
> }
The idea was that ram_discard_manager_replay_discarded() would never be
able to fail. But I don't think this really matters, because the
function is provided by the caller, that can just always return 0 --
like we do in dirty_bitmap_clear_section() now.
So yeah, this looks fine to me, given that we don't call it a "state
change" when we are merely replaying a selected state.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-04-25 12:43 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-07 7:49 [PATCH v4 00/13] Enable shared device assignment Chenyi Qiang
2025-04-07 7:49 ` [PATCH v4 01/13] memory: Export a helper to get intersection of a MemoryRegionSection with a given range Chenyi Qiang
2025-04-09 2:47 ` Alexey Kardashevskiy
2025-04-09 6:26 ` Chenyi Qiang
2025-04-09 6:45 ` Alexey Kardashevskiy
2025-04-09 7:38 ` Chenyi Qiang
2025-05-12 3:24 ` Zhao Liu
2025-04-07 7:49 ` [PATCH v4 02/13] memory: Change memory_region_set_ram_discard_manager() to return the result Chenyi Qiang
2025-04-07 9:53 ` Xiaoyao Li
2025-04-08 0:50 ` Chenyi Qiang
2025-04-09 5:35 ` Alexey Kardashevskiy
2025-04-09 5:52 ` Chenyi Qiang
2025-04-25 12:35 ` David Hildenbrand
2025-04-07 7:49 ` [PATCH v4 03/13] memory: Unify the definiton of ReplayRamPopulate() and ReplayRamDiscard() Chenyi Qiang
2025-04-09 5:43 ` Alexey Kardashevskiy
2025-04-09 6:56 ` Chenyi Qiang
2025-04-25 12:44 ` David Hildenbrand
2025-04-25 12:42 ` David Hildenbrand [this message]
2025-04-27 2:13 ` Chenyi Qiang
2025-04-07 7:49 ` [PATCH v4 04/13] memory: Introduce generic state change parent class for RamDiscardManager Chenyi Qiang
2025-04-09 9:56 ` Alexey Kardashevskiy
2025-04-09 12:57 ` Chenyi Qiang
2025-04-10 0:11 ` Alexey Kardashevskiy
2025-04-10 1:44 ` Chenyi Qiang
2025-04-16 3:32 ` Chenyi Qiang
2025-04-17 23:10 ` Alexey Kardashevskiy
2025-04-18 3:49 ` Chenyi Qiang
2025-04-25 12:54 ` David Hildenbrand
2025-04-25 12:49 ` David Hildenbrand
2025-04-27 1:33 ` Chenyi Qiang
2025-04-07 7:49 ` [PATCH v4 05/13] memory: Introduce PrivateSharedManager Interface as child of GenericStateManager Chenyi Qiang
2025-04-09 9:56 ` Alexey Kardashevskiy
2025-04-10 3:47 ` Chenyi Qiang
2025-04-25 12:57 ` David Hildenbrand
2025-04-27 1:40 ` Chenyi Qiang
2025-04-29 10:01 ` David Hildenbrand
2025-04-07 7:49 ` [PATCH v4 06/13] vfio: Add the support for PrivateSharedManager Interface Chenyi Qiang
2025-04-09 9:58 ` Alexey Kardashevskiy
2025-04-10 5:53 ` Chenyi Qiang
2025-04-07 7:49 ` [PATCH v4 07/13] ram-block-attribute: Introduce RamBlockAttribute to manage RAMBLock with guest_memfd Chenyi Qiang
2025-04-09 9:57 ` Alexey Kardashevskiy
2025-04-10 7:37 ` Chenyi Qiang
2025-05-09 6:41 ` Baolu Lu
2025-05-09 7:55 ` Chenyi Qiang
2025-05-09 8:18 ` David Hildenbrand
2025-05-09 10:37 ` Chenyi Qiang
2025-05-12 8:07 ` Zhao Liu
2025-05-12 9:43 ` Chenyi Qiang
2025-05-13 8:31 ` Zhao Liu
2025-05-14 1:39 ` Chenyi Qiang
2025-04-07 7:49 ` [PATCH v4 08/13] ram-block-attribute: Introduce a callback to notify shared/private state changes Chenyi Qiang
2025-04-07 7:49 ` [PATCH v4 09/13] memory: Attach RamBlockAttribute to guest_memfd-backed RAMBlocks Chenyi Qiang
2025-04-07 7:49 ` [PATCH v4 10/13] memory: Change NotifyStateClear() definition to return the result Chenyi Qiang
2025-04-27 2:26 ` Chenyi Qiang
2025-05-09 2:38 ` Chao Gao
2025-05-09 8:20 ` David Hildenbrand
2025-05-09 9:19 ` Chenyi Qiang
2025-05-09 8:22 ` Baolu Lu
2025-05-09 10:04 ` Chenyi Qiang
2025-05-12 7:54 ` David Hildenbrand
2025-04-07 7:49 ` [PATCH v4 11/13] KVM: Introduce CVMPrivateSharedListener for attribute changes during page conversions Chenyi Qiang
2025-05-09 9:03 ` Baolu Lu
2025-05-12 3:18 ` Chenyi Qiang
2025-04-07 7:49 ` [PATCH v4 12/13] ram-block-attribute: Add priority listener support for PrivateSharedListener Chenyi Qiang
2025-05-09 9:23 ` Baolu Lu
2025-05-09 9:39 ` Chenyi Qiang
2025-04-07 7:49 ` [PATCH v4 13/13] RAMBlock: Make guest_memfd require coordinate discard Chenyi Qiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37cace3c-942e-457d-8a1a-fa37050428a7@redhat.com \
--to=david@redhat.com \
--cc=aik@amd.com \
--cc=chao.gao@intel.com \
--cc=chao.p.peng@intel.com \
--cc=chenyi.qiang@intel.com \
--cc=dan.j.williams@intel.com \
--cc=kvm@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pankaj.gupta@amd.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=xiaoyao.li@intel.com \
--cc=yilun.xu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).