From nobody Tue Sep 22 10:50:16 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1778012956; cv=none; d=zohomail.com; s=zohoarc; b=B1TglA/Oj6tPA925t0INBGYun2QyVeaDmYrcgw6sLPt8dTpJaoW7nQKF2RDNuxXlin7f32YWDOgCcKBNLQMO/47r56KgYGEOSeh3WY2l0pt8/ahxQTJPQUxP70vQwJIoYwVS+3baJqRuXUVt2DxL/mWR6bWdmBCdIgbqCf3x3yE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1778012956; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=9WmFUP5dqUbxMM1tZndsShjc1KEJom3N3hcsbb3ZxQQ=; b=WdxemVz8If5TCgPM3VtGayf8BglhXgXiTOJthNyQKcwSpN2Z0PK/Ws/6wriL1lSFCWEWgAh02xO/qSZA1vR+Av6fG1JwbcYOMzz6fln+Xk/wpMZAn4ILr3rOdxx6PdGltVihP1rfztJKAA1zA5amMW3sX37upX32QQkUuRMZKzU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 177801295686664.3104124702678; Tue, 5 May 2026 13:29:16 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1wKMMN-0004b7-14; Tue, 05 May 2026 16:27:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wKMME-0004Tl-Ct for qemu-devel@nongnu.org; Tue, 05 May 2026 16:27:07 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wKMMC-0002db-PU for qemu-devel@nongnu.org; Tue, 05 May 2026 16:27:06 -0400 Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-20-2be3P9BEP_CRO5WP5KF-LA-1; Tue, 05 May 2026 16:27:02 -0400 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-8b597b14a22so10669136d6.0 for ; Tue, 05 May 2026 13:27:02 -0700 (PDT) Received: from x1.com ([142.189.10.167]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8b53c6b8123sm155283806d6.35.2026.05.05.13.26.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2026 13:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778012823; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9WmFUP5dqUbxMM1tZndsShjc1KEJom3N3hcsbb3ZxQQ=; b=MdKK8UXL+/PA/opfipKtkhXQQPQ8Hr4VNcySliNxnIwheDeglvwC7cFsCPgtGTFX4iB5zX amoeMm1cFR8GoyiMdy5iio2bjmpjljqYjN5/wxKt08dMbRHOlrGBo6876y8LefPw1xKixq BxZHuntCSe+f9/9cGYX1GRslSNGBhUY= X-MC-Unique: 2be3P9BEP_CRO5WP5KF-LA-1 X-Mimecast-MFC-AGG-ID: 2be3P9BEP_CRO5WP5KF-LA_1778012822 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1778012821; x=1778617621; darn=nongnu.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9WmFUP5dqUbxMM1tZndsShjc1KEJom3N3hcsbb3ZxQQ=; b=DWusmMnTi8JNwRLJ/fzDG33CS+LnDFDdAzMcwPEyhTA8Xy9/77f1J+g5iNbnL5HMvK DHR9Jk08LDUl1snuxMnjN8SguPKWGP4WbQcXCeZSdM7FyPQeF1C089ZcKBtRFfLRm/dl kLzpnGNEuPAkKP4RWC7UZOgK+ruJ7ck9Qigi0F/kGCGvBIvbALdsQVgojz5rOPiv4Bji +ltbdinRtngxPLAFm35LtcE4sSk5qLbpD9qzjKuOKq2NPgOH4k5QdWPKLbn5JjfMg2HD pWdUPTwppqpBGVGiVPur3oBay0XvmLJmCOPGbHLgyTrpywECeIbo9cv2Rg4K6eYGaAoC yEMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778012821; x=1778617621; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=9WmFUP5dqUbxMM1tZndsShjc1KEJom3N3hcsbb3ZxQQ=; b=lnR5SZl4TUiBY96bDSGGJPwoWHCwRwiWlrUDTdZPwIsdeYHI7rj9tXDpNlr1w9L4NU OczOYTzw3kYTlU2BBuogYDUfpfPhqv+mOlLTxhkl2o83VxhqNKpalZyyM6MrjWWFNrct Z3eYoLqKQxEafm9O0Sj1RyWjZaMWYnniQZptGMmUjD49iCJ2TKbZoPMitAfgPMPD/8QM SQab1342GXJDa9gIWyskBh8CsMkYHznkvB4+Y9ZabQ54cY+/pVObu2MC8aeTLnr1qJ9F iA167JGSWJ7YSF61IRSUzWoG9t7cOI2Lr3fRx8FaE0mV0PxEpGWYMCeXYDdfkbmqHJf6 QD1g== X-Gm-Message-State: AOJu0YyZdRy3B62QkCL684f5tszc3JZkjL1X0S7nhY99Bk9duN9Ut3G4 H1xRgTh2znari4EaXRFmo28QA4Y6kWkcOhTgA4DCamqshUxKmTMp4w5blEoRbC7T+A6r+bLekRu qwmSPOeCmxqvE4FWKORfXmgD9T8OXyavuHsJghZkt9V9iSRurEfFEBCnXHl0Vc1WMzImIUO24wQ iewFdghFNsoqZV55bnGGiBoJdhsWJh5IzQwxqT7Q== X-Gm-Gg: AeBDiesKtcf01AHrXdxzYwp8zXKZICS8S2NnndSvdEr4Bumr1x0Hx3/MAvpWWYMcZsK 0BATt7gHRFt5eT2XNyMBtful8EIoIOkC6fXPLi/mcgNW6ygraENypTF+vpP5mlhoW1LKu33IiXp qNdTVW46SnyKNn2tM+0i2j8Py68nvXS1KQs/6sZeGfAiQF+5W+X5pRUVD1cxfASJ4rEX0/PtyrR rVh3ADwC1lGdZeCDzAyONC/gPi8iM8czEFiqZPJy0cspuPK1qNrJ9A/UmFggNtCZZLpJgFoBzqu xJXSp0hZ0sezjj6eIv5os8VevqV92SBr7ZLz4xGFjnfxVtioOXTcthBcuQzLFi017Q2wmii8IZg kIs/bkkBfmQH8s3L38QpiLxY0iEnTKy+wjBr+aJ3qE4QfBdo9zklJfl0= X-Received: by 2002:a05:6214:5503:b0:896:fb99:f692 with SMTP id 6a1803df08f44-8bc2a3b6da3mr9953536d6.0.1778012821247; Tue, 05 May 2026 13:27:01 -0700 (PDT) X-Received: by 2002:a05:6214:5503:b0:896:fb99:f692 with SMTP id 6a1803df08f44-8bc2a3b6da3mr9952896d6.0.1778012820570; Tue, 05 May 2026 13:27:00 -0700 (PDT) From: Peter Xu To: qemu-devel@nongnu.org Cc: Fabiano Rosas , Paolo Bonzini , Peter Xu , =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= , Juraj Marcin Subject: [PULL 14/23] migration: Fix calculation of expected_downtime to take VFIO info Date: Tue, 5 May 2026 16:26:31 -0400 Message-ID: <20260505202640.1011006-15-peterx@redhat.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260505202640.1011006-1-peterx@redhat.com> References: <20260505202640.1011006-1-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=peterx@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.443, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1778012958596158500 QEMU will provide an expected downtime for the whole system during migration, by remembering the total dirty RAM that we synced the last time, divides the estimated switchover bandwidth. That was flawed when VFIO is taking into account: consider there is a VFIO GPU device that contains GBs of data to migrate during stop phase. Those will not be accounted in this math. Fix it by updating dirty_bytes_last_sync properly only when we go to the next iteration, rather than hide this update in the RAM code. Meanwhile, fetch the total (rather than RAM-only) portion of dirty bytes, so as to include GPU device states too. Update the comment of the field to reflect its new meaning. Now after this change, the expected-downtime to be read from query-migrate should be very accurate even with VFIO devices involved. Tested-by: C=C3=A9dric Le Goater Reviewed-by: Juraj Marcin Link: https://lore.kernel.org/r/20260421202110.306051-13-peterx@redhat.com Signed-off-by: Peter Xu --- migration/migration-stats.h | 8 +++----- migration/migration.c | 11 ++++++++--- migration/ram.c | 1 - 3 files changed, 11 insertions(+), 9 deletions(-) diff --git a/migration/migration-stats.h b/migration/migration-stats.h index 326ddb0088..1775b916df 100644 --- a/migration/migration-stats.h +++ b/migration/migration-stats.h @@ -31,11 +31,9 @@ */ typedef struct { /* - * Number of bytes that were dirty last time that we synced with - * the guest memory. We use that to calculate the downtime. As - * the remaining dirty amounts to what we know that is still dirty - * since last iteration, not counting what the guest has dirtied - * since we synchronized bitmaps. + * Number of bytes that were reported dirty after the latest + * system-wise synchronization of dirty information. It is used to do + * best-effort estimation on expected downtime. */ uint64_t dirty_bytes_last_sync; /* diff --git a/migration/migration.c b/migration/migration.c index d740d9df85..ab09dcbcf4 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -3244,18 +3244,23 @@ static void migration_iteration_go_next(MigPendingD= ata *pending) */ qemu_savevm_query_pending(pending, true); =20 + /* + * Update the dirty information for the whole system for this + * iteration. This value is used to calculate expected downtime. + */ + qatomic_set(&mig_stats.dirty_bytes_last_sync, pending->total_bytes); + /* * Boost dirty sync count to reflect we finished one iteration. * * NOTE: we need to make sure when this happens (together with the * event sent below) all modules have slow-synced the pending data - * above. That means a write mem barrier, but qatomic_add() should be - * enough. + * above and updated corresponding fields (e.g. dirty_bytes_last_sync). * * It's because a mgmt could wait on the iteration event to query again * on pending data for policy changes (e.g. downtime adjustments). The * ordering will make sure the query will fetch the latest results from - * all the modules. + * all the modules on everything. */ qatomic_add(&mig_stats.dirty_sync_count, 1); =20 diff --git a/migration/ram.c b/migration/ram.c index ecd4b6165c..fc38ffbf8a 100644 --- a/migration/ram.c +++ b/migration/ram.c @@ -1148,7 +1148,6 @@ static void migration_bitmap_sync(RAMState *rs, bool = last_stage) RAMBLOCK_FOREACH_NOT_IGNORED(block) { ramblock_sync_dirty_bitmap(rs, block); } - qatomic_set(&mig_stats.dirty_bytes_last_sync, ram_bytes_remain= ing()); } } =20 --=20 2.53.0