From: sashiko-bot@kernel.org
To: "Shivank Garg" <shivankg@amd.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH RFC v2 4/4] KVM: selftests: exercise guest_memfd folio migration
Date: Tue, 28 Jul 2026 09:19:45 +0000 [thread overview]
Message-ID: <20260728091945.EA6C31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260728-shivank-gmem-migrate-v2-4-269ac1f84e2b@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Hardcoding of NUMA node IDs 0 and 1 makes the test brittle and prone to false failures on systems with sparse, non-contiguous, or memoryless nodes.
--
--- Patch [4]: [PATCH RFC v2 4/4] KVM: selftests: exercise guest_memfd folio migration ---
commit 3681825fc67afc2ab3cf2b50c6cec1297cae94b5
Author: Shivank Garg <shivankg@amd.com>
KVM: selftests: exercise guest_memfd folio migration
This commit adds a migration test to guest_memfd_test to verify that
guest_memfd folios can be migrated across NUMA nodes using move_pages().
It allocates folios on node 0, migrates them to node 1, verifies the
contents, and then migrates them back.
> diff --git a/tools/testing/selftests/kvm/guest_memfd_test.c b/tools/testing/selftests/kvm/guest_memfd_test.c
> --- a/tools/testing/selftests/kvm/guest_memfd_test.c
> +++ b/tools/testing/selftests/kvm/guest_memfd_test.c
[ ... ]
> +static void test_migrate_folio(int fd, size_t total_size)
> +{
> + const unsigned long nodemask_0 = 1; /* nid: 0 */
> + unsigned long maxnode = BITS_PER_TYPE(nodemask_0);
> + int page_count = total_size / page_size;
> + int *status, *nodes;
> + void **addr;
> + char *mem;
> + int i;
> +
> + if (!is_multi_numa_node_system())
> + return;
> +
> + mem = kvm_mmap(total_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd);
> +
> + addr = calloc(page_count, sizeof(*addr));
> + status = calloc(page_count, sizeof(*status));
> + nodes = calloc(page_count, sizeof(*nodes));
> + TEST_ASSERT(addr && status && nodes, "Failed to allocate page arrays");
> +
> + /* Allocate all folios on node 0 and fill each with a known pattern. */
> + kvm_mbind(mem, total_size, MPOL_BIND, &nodemask_0, maxnode, 0);
> + for (i = 0; i < page_count; i++) {
> + memset(mem + i * page_size, (char)(i & 0xff), page_size);
> + addr[i] = mem + i * page_size;
> + }
> +
> + kvm_move_pages(0, page_count, addr, NULL, status, 0);
> + for (i = 0; i < page_count; i++)
> + TEST_ASSERT(status[i] == 0, "Page %d should be on node 0", i);
> +
> + /* Migrate node 0 -> 1, then check both the location and the data. */
> + for (i = 0; i < page_count; i++)
> + nodes[i] = 1;
[Severity: Medium]
Could this hardcoding of NUMA node IDs cause false positive test failures?
If a system has sparse, non-contiguous, or memoryless nodes (for example,
nodes 0 and 2 exist, but node 1 is absent), is_multi_numa_node_system()
will return true, but the initial allocation on node 0 or the migration to
node 1 could fail.
Would it be better to dynamically discover available memory nodes in
test_migrate_folio() instead of assuming nodes 0 and 1 always exist and
have memory available?
> + kvm_move_pages(0, page_count, addr, nodes, status, MPOL_MF_MOVE);
> +
> + kvm_move_pages(0, page_count, addr, NULL, status, 0);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260728-shivank-gmem-migrate-v2-0-269ac1f84e2b@amd.com?part=4
prev parent reply other threads:[~2026-07-28 9:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 9:05 [PATCH RFC v2 0/4] KVM: guest_memfd: folio migration for non-confidential VMs Shivank Garg
2026-07-28 9:05 ` [PATCH RFC v2 1/4] mm: split AS_UNMOVABLE back out of AS_INACCESSIBLE Shivank Garg
2026-07-28 9:05 ` [PATCH RFC v2 2/4] KVM: guest_memfd: implement folio migration for non-confidential VMs Shivank Garg
2026-07-28 9:20 ` sashiko-bot
2026-07-28 9:05 ` [PATCH RFC v2 3/4] KVM: guest_memfd: add GUEST_MEMFD_FLAG_MIGRATABLE Shivank Garg
2026-07-28 9:28 ` sashiko-bot
2026-07-28 9:05 ` [PATCH RFC v2 4/4] KVM: selftests: exercise guest_memfd folio migration Shivank Garg
2026-07-28 9:19 ` sashiko-bot [this message]
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=20260728091945.EA6C31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shivankg@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.