From: Peter Xu <peterx@redhat.com>
To: "Zhijian Li (Fujitsu)" <lizhijian@fujitsu.com>
Cc: Fabiano Rosas <farosas@suse.de>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Laurent Vivier <lvivier@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Jack Wang <jinpu.wang@ionos.com>,
"Michael R . Galaxy" <mrgalaxy@nvidia.com>,
Yu Zhang <yu.zhang@ionos.com>
Subject: Re: [PATCH] qtest/migration/rdma: Add test for rdma migration with ipv6
Date: Wed, 30 Apr 2025 17:52:47 -0400 [thread overview]
Message-ID: <aBKbr3aVAxAwt2rD@x1.local> (raw)
In-Reply-To: <396fcfe6-7ddb-41e7-ae28-e5210dea7dd7@fujitsu.com>
On Wed, Apr 30, 2025 at 09:49:40AM +0000, Zhijian Li (Fujitsu) wrote:
>
>
> On 30/04/2025 16:48, Zhijian Li (Fujitsu) via wrote:
> >>> stderr:
> >>> qemu-system-x86_64: cannot get rkey
> >>> qemu-system-x86_64: error while loading state section id 2(ram)
> >>> qemu-system-x86_64: load of migration failed: Operation not permitted
> >>> qemu-system-x86_64: rdma migration: recv polling control error!
> >>> qemu-system-x86_64: RDMA is in an error state waiting migration to abort!
> >>> qemu-system-x86_64: failed to save SaveStateEntry with id(name): 2(ram): -1
> >>> qemu-system-x86_64: Channel error: Operation not permitted
> >>> **
> >>> ERROR:../tests/qtest/migration/migration-qmp.c:200:check_migration_status: assertion failed (current_status != "failed"): ("failed" != "failed")
> >>> qemu-system-x86_64: warning: Early error. Sending error.
> >>> qemu-system-x86_64: warning: rdma migration: send polling control error
> >>> ../tests/qtest/libqtest.c:199: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0)
> >>>
> >>> So running the test also needs root? Is it possible we fix the test so it
> >>> can also be smart enough to skip if it knows it'll hit the "cannot get
> >>> rkey" error (even if it sees the rdma link setup)? Not something urgent
> >>> but definitely good to have.
> > It seems it's a security problem, I have no a good idea yet.
> >
> > Let me see see...
>
> Another workaround is update the 'ulimit -l' to >=128M for a non-root user(in practice
> this value works well on fedora40)
OK so it's about the locked mem.. thanks for looking.
>
> So we would have something like this:
>
> diff --git a/tests/qtest/migration/precopy-tests.c b/tests/qtest/migration/precopy-tests.c
> index 9f7236dc59f..1f24753c5a5 100644
> --- a/tests/qtest/migration/precopy-tests.c
> +++ b/tests/qtest/migration/precopy-tests.c
> @@ -101,6 +101,26 @@ static void test_precopy_unix_dirty_ring(void)
>
> #ifdef CONFIG_RDMA
>
> +#include <sys/resource.h>
> +#define REQUIRED_MEMLOCK (128 * 1024 * 1024) // 128MB
How does the 128M come from? Is it correlated to the VM size somehow?
Btw, migrate_start() says for x86 we use 150MB VM.
When you feel confident, feel free to send a formal patch, it can also
include the reposted version of the current patch so that can be a series.
It'll also be great if you could make sure they apply on top of:
https://gitlab.com/peterx/qemu/-/tree/migration-staging
Thanks,
> +
> +static bool mlock_check(void)
> +{
> + uid_t uid;
> + struct rlimit rlim;
> +
> + uid = getuid();
> + if (uid == 0) {
> + return true;
> + }
> +
> + if (getrlimit(RLIMIT_MEMLOCK, &rlim) != 0) {
> + return false;
> + }
> +
> + return rlim.rlim_cur >= REQUIRED_MEMLOCK;
> +}
> +
> #define RDMA_MIGRATION_HELPER "scripts/rdma-migration-helper.sh"
> static int new_rdma_link(char *buffer, bool ipv6)
> {
> @@ -137,6 +157,11 @@ static void test_precopy_rdma_plain_ip(bool ipv6)
> {
> char buffer[128] = {};
>
> + if (!mlock_check()) {
> + g_test_skip("'ulimit -l' is too small, require 128M");
> + return;
> + }
> +
> if (new_rdma_link(buffer, ipv6)) {
> g_test_skip("No rdma link available\n"
> "# To enable the test:\n"
--
Peter Xu
next prev parent reply other threads:[~2025-04-30 21:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-27 2:12 [PATCH] qtest/migration/rdma: Add test for rdma migration with ipv6 Li Zhijian via
2025-03-27 6:17 ` Jinpu Wang
2025-04-29 21:09 ` Peter Xu
2025-04-30 8:28 ` Zhijian Li (Fujitsu) via
2025-04-30 8:48 ` Zhijian Li (Fujitsu) via
2025-04-30 9:49 ` Zhijian Li (Fujitsu) via
2025-04-30 21:52 ` Peter Xu [this message]
2025-05-07 7:02 ` Zhijian Li (Fujitsu) via
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=aBKbr3aVAxAwt2rD@x1.local \
--to=peterx@redhat.com \
--cc=farosas@suse.de \
--cc=jinpu.wang@ionos.com \
--cc=lizhijian@fujitsu.com \
--cc=lvivier@redhat.com \
--cc=mrgalaxy@nvidia.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yu.zhang@ionos.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).