From nobody Mon Feb 9 17:34:53 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1698153398; cv=none; d=zohomail.com; s=zohoarc; b=JA4qrbW+8mpHiBJ11gC7gnLTIYLt9q9GsXUo8nCD7EIoV033vQWHoaLgovhiV84udWlvoG/CysdUnuNuDKB2/KkbvvOrA7m/HekBHDgrbkHvSarlZAxGkh8mh8YOahtAj/QSMRrzGOnWokjqFoxaxZNfgz+8YTIKv/AEJnmL38Y= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1698153398; 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=rLdOgQORj/Nl035a1TnFgLX0gwiYcob+wD6YkWCXdyk=; b=LDzOMJtoOxcWTgHd7pA1vRieIvegD5q2qEFYKMkd4SWQ1aa3Vloh0ydttEed57Cs8ES4JtAs3jyXg+9q59BdJrRDP2sgx8nUppdQlF4g6Pj+1uyOOy//JCJz9xunFdeoetY3ccJcL1LpfAB4xpfo3epPmzKQVpb/BAOnXyKkLNA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.zohomail.com with SMTPS id 1698153398745389.0672586649007; Tue, 24 Oct 2023 06:16:38 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-195-wd1lJe9hNY-keHuThSimtg-1; Tue, 24 Oct 2023 09:16:34 -0400 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7C69980171C; Tue, 24 Oct 2023 13:16:30 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6A263492BFB; Tue, 24 Oct 2023 13:16:30 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 3D5C6194658C; Tue, 24 Oct 2023 13:16:30 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 6382A1946586 for ; Tue, 24 Oct 2023 13:16:28 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 556951C060BD; Tue, 24 Oct 2023 13:16:28 +0000 (UTC) Received: from secure.mitica (unknown [10.39.194.127]) by smtp.corp.redhat.com (Postfix) with ESMTP id 95BF81C060AE; Tue, 24 Oct 2023 13:16:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698153397; h=from:from:sender:sender: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:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=rLdOgQORj/Nl035a1TnFgLX0gwiYcob+wD6YkWCXdyk=; b=D/OoWQhcbSy0KoYx7eYZNZE3TVaB51GMJbgWM8dvRXAT+YHSmYF0tZYmqv/p8nw/ddjTRj NoVLHzmfNUTlTJt+5ZeVeGnceUtcmTECnycsZsu2aq2ZspqUNn1VC9PCPNBz1StIzuvKGk Gu616ajKAsvtB38eq3dK4Ve/wZBi+dA= X-MC-Unique: wd1lJe9hNY-keHuThSimtg-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Juan Quintela To: qemu-devel@nongnu.org Subject: [PULL 29/39] migration: Hack to maintain backwards compatibility for ppc Date: Tue, 24 Oct 2023 15:12:55 +0200 Message-ID: <20231024131305.87468-30-quintela@redhat.com> In-Reply-To: <20231024131305.87468-1-quintela@redhat.com> References: <20231024131305.87468-1-quintela@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Fam Zheng , Peter Maydell , Corey Minyard , libvir-list@redhat.com, Jason Wang , Mark Cave-Ayland , Li Zhijian , Peter Xu , Gerd Hoffmann , Eric Blake , Fabiano Rosas , qemu-block@nongnu.org, Juan Quintela , Daniel Henrique Barboza , Markus Armbruster , Halil Pasic , Marcel Apfelbaum , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Christian Borntraeger , Thomas Huth , Corey Minyard , Harsh Prateek Bora , Stefan Weil , Richard Henderson , Greg Kurz , Nicholas Piggin , qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= , Stefan Hajnoczi , Samuel Thibault , David Hildenbrand , John Snow , David Gibson , Kevin Wolf , "Michael S. Tsirkin" , Ilya Leoshkevich , Hanna Reitz , Leonardo Bras , qemu-ppc@nongnu.org Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1698153411217100001 Content-Type: text/plain; charset="utf-8"; x-default="true" Current code does: - register pre_2_10_vmstate_dummy_icp with "icp/server" and instance dependinfg on cpu number - for newer machines, it register vmstate_icp with "icp/server" name and instance 0 - now it unregisters "icp/server" for the 1st instance. This is wrong at many levels: - we shouldn't have two VMSTATEDescriptions with the same name - In case this is the only solution that we can came with, it needs to be: * register pre_2_10_vmstate_dummy_icp * unregister pre_2_10_vmstate_dummy_icp * register real vmstate_icp Created vmstate_replace_hack_for_ppc() with warnings left and right that it is a hack. CC: Cedric Le Goater CC: Daniel Henrique Barboza CC: David Gibson CC: Greg Kurz Reviewed-by: Nicholas Piggin Signed-off-by: Juan Quintela Message-ID: <20231020090731.28701-8-quintela@redhat.com> --- include/migration/vmstate.h | 11 +++++++++++ hw/intc/xics.c | 18 ++++++++++++++++-- hw/ppc/spapr.c | 25 +++++++++++++++++++++++-- migration/savevm.c | 18 ++++++++++++++++++ 4 files changed, 68 insertions(+), 4 deletions(-) diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h index 1ea97ccf2d..9821918631 100644 --- a/include/migration/vmstate.h +++ b/include/migration/vmstate.h @@ -1230,6 +1230,17 @@ static inline int vmstate_register(VMStateIf *obj, i= nt instance_id, opaque, -1, 0, NULL); } =20 +/** + * vmstate_replace_hack_for_ppc() - ppc used to abuse vmstate_register + * + * Don't even think about using this function in new code. + * + * Returns: 0 on success, -1 on failure + */ +int vmstate_replace_hack_for_ppc(VMStateIf *obj, int instance_id, + const VMStateDescription *vmsd, + void *opaque); + /** * vmstate_register_any() - legacy function to register state * serialisation description and let the function choose the id diff --git a/hw/intc/xics.c b/hw/intc/xics.c index c7f8abd71e..c77e986136 100644 --- a/hw/intc/xics.c +++ b/hw/intc/xics.c @@ -335,8 +335,22 @@ static void icp_realize(DeviceState *dev, Error **errp) return; } } - - vmstate_register(NULL, icp->cs->cpu_index, &vmstate_icp_server, icp); + /* + * The way that pre_2_10_icp is handling is really, really hacky. + * We used to have here this call: + * + * vmstate_register(NULL, icp->cs->cpu_index, &vmstate_icp_server, icp= ); + * + * But we were doing: + * pre_2_10_vmstate_register_dummy_icp() + * this vmstate_register() + * pre_2_10_vmstate_unregister_dummy_icp() + * + * So for a short amount of time we had to vmstate entries with + * the same name. This fixes it. + */ + vmstate_replace_hack_for_ppc(NULL, icp->cs->cpu_index, + &vmstate_icp_server, icp); } =20 static void icp_unrealize(DeviceState *dev) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index b25093be28..df09aa9d6a 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -143,6 +143,11 @@ static bool pre_2_10_vmstate_dummy_icp_needed(void *op= aque) } =20 static const VMStateDescription pre_2_10_vmstate_dummy_icp =3D { + /* + * Hack ahead. We can't have two devices with the same name and + * instance id. So I rename this to pass make check. + * Real help from people who knows the hardware is needed. + */ .name =3D "icp/server", .version_id =3D 1, .minimum_version_id =3D 1, @@ -155,16 +160,32 @@ static const VMStateDescription pre_2_10_vmstate_dumm= y_icp =3D { }, }; =20 +/* + * See comment in hw/intc/xics.c:icp_realize() + * + * You have to remove vmstate_replace_hack_for_ppc() when you remove + * the machine types that need the following function. + */ static void pre_2_10_vmstate_register_dummy_icp(int i) { vmstate_register(NULL, i, &pre_2_10_vmstate_dummy_icp, (void *)(uintptr_t) i); } =20 +/* + * See comment in hw/intc/xics.c:icp_realize() + * + * You have to remove vmstate_replace_hack_for_ppc() when you remove + * the machine types that need the following function. + */ static void pre_2_10_vmstate_unregister_dummy_icp(int i) { - vmstate_unregister(NULL, &pre_2_10_vmstate_dummy_icp, - (void *)(uintptr_t) i); + /* + * This used to be: + * + * vmstate_unregister(NULL, &pre_2_10_vmstate_dummy_icp, + * (void *)(uintptr_t) i); + */ } =20 int spapr_max_server_number(SpaprMachineState *spapr) diff --git a/migration/savevm.c b/migration/savevm.c index ca5c7cebe0..1d1639c4b6 100644 --- a/migration/savevm.c +++ b/migration/savevm.c @@ -846,6 +846,24 @@ static void vmstate_check(const VMStateDescription *vm= sd) } } =20 +/* + * See comment in hw/intc/xics.c:icp_realize() + * + * This function can be removed when + * pre_2_10_vmstate_register_dummy_icp() is removed. + */ +int vmstate_replace_hack_for_ppc(VMStateIf *obj, int instance_id, + const VMStateDescription *vmsd, + void *opaque) +{ + SaveStateEntry *se =3D find_se(vmsd->name, instance_id); + + if (se) { + savevm_state_handler_remove(se); + } + return vmstate_register(obj, instance_id, vmsd, opaque); +} + int vmstate_register_with_alias_id(VMStateIf *obj, uint32_t instance_id, const VMStateDescription *vmsd, void *opaque, int alias_id, --=20 2.41.0