From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F1AF3CC6B2F for ; Thu, 15 Oct 2026 05:07:43 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1xHDgX-0003e1-GX; Thu, 15 Oct 2026 01:07:22 -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 1xHDgV-0003dr-BR for qemu-devel@nongnu.org; Thu, 15 Oct 2026 01:07:20 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1xHDgT-0007yI-2t for qemu-devel@nongnu.org; Thu, 15 Oct 2026 01:07:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792040835; 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: in-reply-to:in-reply-to:references:references; bh=INdKPlSZPizcpEjdMeGRENfyzOCrbnidkEG9iYo/P8Y=; b=Jcq+cnKD9el9Q+s5aB0iKgSqLM5G9oZYl14ougaRBIWhHN5z9i/jpwjz85vOhcAQiAsqSl AtyIU7wh0ZJkprCKZC2KBS87wbBslzEiJntYfwtENxlguq7KMgK6X5GFjltE1doN28/rqk 8z2FRYF81OKtazK/Kb3KSK1pDgDKljg= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-303-JD2LEjWYM_eZ7N6js58zHg-1; Thu, 15 Oct 2026 05:07:10 +0000 X-MC-Unique: JD2LEjWYM_eZ7N6js58zHg-1 X-Mimecast-MFC-AGG-ID: JD2LEjWYM_eZ7N6js58zHg_1792040828 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 44F971954199; Thu, 15 Oct 2026 05:06:29 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.2]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 958AB30001A2; Thu, 15 Oct 2026 05:06:28 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 4DBE321E6A04; Thu, 15 Oct 2026 07:06:26 +0200 (CEST) From: Markus Armbruster To: Dongli Zhang Cc: qemu-devel@nongnu.org, david@kernel.org, imammedo@redhat.com, maciej.szmigiero@oracle.com, peterx@redhat.com, farosas@suse.de, mark.kanda@oracle.com, bchaney@akamai.com, pierrick.bouvier@oss.qualcomm.com, alex@shazbot.org, clg@redhat.com, yi.l.liu@intel.com, eric.auger@redhat.com, zhenzhong.duan@intel.com, mst@redhat.com, cohuck@redhat.com, pbonzini@redhat.com, eblake@redhat.com Subject: Re: [PATCH 01/21] qapi/migration: add cpr-luo migration mode In-Reply-To: <4b7de1ba-f063-43b9-9dd2-64d1187e488f@oracle.com> (Dongli Zhang's message of "Wed, 14 Oct 2026 08:52:24 -0700") References: <20261012235727.398133-1-dongli.zhang@oracle.com> <20261012235727.398133-2-dongli.zhang@oracle.com> <878q40eni8.fsf@pond.sub.org> <4b7de1ba-f063-43b9-9dd2-64d1187e488f@oracle.com> Date: Thu, 15 Oct 2026 07:06:26 +0200 Message-ID: <87qzhrblil.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Received-SPF: pass client-ip=170.10.129.124; envelope-from=armbru@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: 10 X-Spam_score: 1.0 X-Spam_bar: + X-Spam_report: (1.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.24, 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_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no 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+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Dongli Zhang writes: > On Wed, Oct 14, 2026 12:42:55AM -0700, Markus Armbruster wrote: >> Dongli Zhang writes: >> >>> Add the cpr-luo migration mode for CPR through the Linux Live Update >>> Orchestrator (LUO). Subsequent changes preserve CPR state and RAMBlock >>> backing file descriptors in an LUO session across a host kernel update. >>> >>> Signed-off-by: Dongli Zhang >>> --- >>> qapi/migration.json | 11 ++++++++++- >>> 1 file changed, 10 insertions(+), 1 deletion(-) >>> >>> diff --git a/qapi/migration.json b/qapi/migration.json >>> index 889a9b89c2..ab117c3897 100644 >>> --- a/qapi/migration.json >>> +++ b/qapi/migration.json >>> @@ -712,9 +712,18 @@ >>> # with the '-machine aux-ram-share=on' option. >>> # >>> # (since 10.2) >>> +# >>> +# @cpr-luo: A CPR mode that preserves guest RAM backing file >>> +# descriptors and CPR state through the Linux Live Update >>> +# Orchestrator (LUO) across a host kernel update. >>> +# >>> +# This mode requires Linux with LUO support. >> >> Pardon my ignorant question: host or guest kernel? >> > Host KVM kernel. Suggest something like "This mode requires Linux with LUO support on the host", or "This mode requires the host to run Linux with LUO support". > cpr-luo is more similar to cpr-exec (assuming VFIO is not involved). > > cpr-exec (same process across exec): > > - RAMBlock fds are preserved across exec(). The metadata is transferred to the > target via a memfd passed through an environment variable. > - The device state (i.e., virtio) is transferred through the main stream (i.e., > a file). > > cpr-transfer (two processes): > > - RAMBlock fds are preserved and transferred to the target QEMU via a UNIX > domain socket. > - The device state (i.e., virtio) is transferred through the main stream (i.e., > local TCP). > > cpr-reboot (across reboot): > > - The RAMBlock is always reconstructed. It is just a matter of whether to > save/load the memory data, depending on whether x-ignore-shared is enabled. > - The vmstate (i.e., virtio) is transferred through the main stream (i.e., a file). > > New cpr-luo (across kexec/LUO/KHO): > > - RAMBlock fds are preserved and transferred across kexec to the target QEMU via > LUO/KHO, identified by a LUO session and tokens. > - The device state (i.e., virtio) is transferred through the main stream (i.e., > a file). Is this covered in the documentation? > Thank you very much! > > Dongli Zhang You're welcome!