qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: peterx@redhat.com
To: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Cc: peterx@redhat.com, "Fabiano Rosas" <farosas@suse.de>,
	"Daniel P. Berrangé" <berrange@redhat.com>
Subject: [PULL 32/34] tests/migration-test: Stick with gicv3 in aarch64 test
Date: Thu,  8 Feb 2024 11:05:26 +0800	[thread overview]
Message-ID: <20240208030528.368214-33-peterx@redhat.com> (raw)
In-Reply-To: <20240208030528.368214-1-peterx@redhat.com>

From: Peter Xu <peterx@redhat.com>

Recently we introduced cross-binary migration test.  It's always wanted
that migration-test uses stable guest ABI for both QEMU binaries in this
case, so that both QEMU binaries will be compatible on the migration
stream with the cmdline specified.

Switch to a static gic version "3" rather than using version "max", so that
GIC should be stable now across any future QEMU binaries for migration-test.

Here the version can actually be anything as long as the ABI is stable.  We
choose "3" because it's the majority of what we already use in QEMU while
still new enough: "git grep gic-version=3" shows 6 hit, while version 4 has
no direct user yet besides "max".

Note that even with this change, aarch64 won't be able to work yet with
migration cross binary test, but then the only missing piece will be the
stable CPU model.

Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com>
Link: https://lore.kernel.org/r/20240207005403.242235-2-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
---
 tests/qtest/migration-test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index 7675519cfa..8a5bb1752e 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -819,7 +819,7 @@ static int test_migrate_start(QTestState **from, QTestState **to,
     } else if (strcmp(arch, "aarch64") == 0) {
         memory_size = "150M";
         machine_alias = "virt";
-        machine_opts = "gic-version=max";
+        machine_opts = "gic-version=3";
         arch_opts = g_strdup_printf("-cpu max -kernel %s", bootpath);
         start_address = ARM_TEST_MEM_START;
         end_address = ARM_TEST_MEM_END;
-- 
2.43.0



  parent reply	other threads:[~2024-02-08  3:08 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-08  3:04 [PULL 00/34] Migration staging patches peterx
2024-02-08  3:04 ` [PULL 01/34] migration: prevent migration when VM has poisoned memory peterx
2024-02-08  3:04 ` [PULL 02/34] migration/multifd: Drop stale comment for multifd zero copy peterx
2024-02-08  3:04 ` [PULL 03/34] migration/multifd: multifd_send_kick_main() peterx
2024-02-08  3:04 ` [PULL 04/34] migration/multifd: Drop MultiFDSendParams.quit, cleanup error paths peterx
2024-02-08  3:04 ` [PULL 05/34] migration/multifd: Postpone reset of MultiFDPages_t peterx
2024-02-08  3:05 ` [PULL 06/34] migration/multifd: Drop MultiFDSendParams.normal[] array peterx
2024-02-08  3:05 ` [PULL 07/34] migration/multifd: Separate SYNC request with normal jobs peterx
2024-02-08  3:05 ` [PULL 08/34] migration/multifd: Simplify locking in sender thread peterx
2024-02-08  3:05 ` [PULL 09/34] migration/multifd: Drop pages->num check " peterx
2024-02-08  3:05 ` [PULL 10/34] migration/multifd: Rename p->num_packets and clean it up peterx
2024-02-08  3:05 ` [PULL 11/34] migration/multifd: Move total_normal_pages accounting peterx
2024-02-08  3:05 ` [PULL 12/34] migration/multifd: Move trace_multifd_send|recv() peterx
2024-02-08  3:05 ` [PULL 13/34] migration/multifd: multifd_send_prepare_header() peterx
2024-02-08  3:05 ` [PULL 14/34] migration/multifd: Move header prepare/fill into send_prepare() peterx
2024-02-08  3:05 ` [PULL 15/34] migration/multifd: Forbid spurious wakeups peterx
2024-02-08  3:05 ` [PULL 16/34] migration/multifd: Split multifd_send_terminate_threads() peterx
2024-02-08  3:05 ` [PULL 17/34] migration/multifd: Change retval of multifd_queue_page() peterx
2024-02-08  3:05 ` [PULL 18/34] migration/multifd: Change retval of multifd_send_pages() peterx
2024-02-08  3:05 ` [PULL 19/34] migration/multifd: Rewrite multifd_queue_page() peterx
2024-02-08  3:05 ` [PULL 20/34] migration/multifd: Cleanup multifd_save_cleanup() peterx
2024-02-08  3:05 ` [PULL 21/34] migration/multifd: Cleanup multifd_load_cleanup() peterx
2024-02-08  3:05 ` [PULL 22/34] migration/multifd: Stick with send/recv on function names peterx
2024-02-08  3:05 ` [PULL 23/34] migration/multifd: Fix MultiFDSendParams.packet_num race peterx
2024-02-08  3:05 ` [PULL 24/34] migration/multifd: Optimize sender side to be lockless peterx
2024-02-08  3:05 ` [PULL 25/34] migration: Fix logic of channels and transport compatibility check peterx
2024-02-08  3:05 ` [PULL 26/34] migration/multifd: Join the TLS thread peterx
2024-02-10  9:18   ` Michael Tokarev
2024-02-10  9:30     ` Michael Tokarev
2024-02-14 13:27       ` Fabiano Rosas
2024-02-14 13:58         ` Michael Tokarev
2024-02-15 13:24           ` Fabiano Rosas
2024-02-08  3:05 ` [PULL 27/34] migration/multifd: Remove p->running peterx
2024-02-08  3:05 ` [PULL 28/34] migration/multifd: Move multifd_send_setup error handling in to the function peterx
2024-02-08  3:05 ` [PULL 29/34] migration/multifd: Move multifd_send_setup into migration thread peterx
2024-02-08  3:05 ` [PULL 30/34] migration/multifd: Unify multifd and TLS connection paths peterx
2024-02-08  3:05 ` [PULL 31/34] migration/multifd: Add a synchronization point for channel creation peterx
2024-02-08  3:05 ` peterx [this message]
2024-02-08  3:05 ` [PULL 33/34] ci: Remove tag dependency for build-previous-qemu peterx
2024-02-08  3:05 ` [PULL 34/34] ci: Update comment for migration-compat-aarch64 peterx
2024-02-09 16:14 ` [PULL 00/34] Migration staging patches Peter Maydell

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=20240208030528.368214-33-peterx@redhat.com \
    --to=peterx@redhat.com \
    --cc=berrange@redhat.com \
    --cc=farosas@suse.de \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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).