From nobody Thu Oct 31 00:19:23 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1722520412153282.0222944778676; Thu, 1 Aug 2024 06:53:32 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 1A08E13E1; Thu, 1 Aug 2024 09:53:31 -0400 (EDT) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 12A101306; Thu, 1 Aug 2024 09:53:08 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 8ADAB11F8; Thu, 1 Aug 2024 09:53:05 -0400 (EDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 1133811E2 for ; Thu, 1 Aug 2024 09:53:05 -0400 (EDT) Received: from mx-prod-mc-04.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-61--Ak_bgHAP4CuVYFj31fdYg-1; Thu, 01 Aug 2024 09:53:03 -0400 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (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-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id BC66319560B0 for ; Thu, 1 Aug 2024 13:53:02 +0000 (UTC) Received: from speedmetal.redhat.com (unknown [10.45.242.16]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E01811955D42 for ; Thu, 1 Aug 2024 13:53:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722520384; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eBPaxsoDMoSE8vwku2WuykxsJFFIF51/RUjGiMOXkp8=; b=gCUN7jN4kmc3g3E3RuZr/gVKljwub2tkWk5bJmNXe1+Ngir4eKiuxxz9o7R1y+NJ0ctzh4 D9Cbyd6dVasEMBNe/N7tH4Al00+vN7vj+4cGchtg+yExRI8nV0cPQIhXEnIneZ1alTM7aT yCzHDqPdGV82eZqujBBF17v3EDCDVnw= X-MC-Unique: -Ak_bgHAP4CuVYFj31fdYg-1 From: Peter Krempa To: devel@lists.libvirt.org Subject: [PATCH v2 1/2] qemu_domain: Strip from s390(x) definitions Date: Thu, 1 Aug 2024 15:52:57 +0200 Message-ID: <6e3edd6453f3cb6e6cce9abc5615739b3462f28c.1722520223.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: ZV7MRVE347S5RF55LA3DMSTXX4JB4BZE X-Message-ID-Hash: ZV7MRVE347S5RF55LA3DMSTXX4JB4BZE X-MailFrom: pkrempa@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1722520412723116600 Content-Type: text/plain; charset="utf-8" The s390(x) machines never supported ACPI. That didn't stop users enabling ACPI in their config. As of libvirt-9.2 (98c4e3d073) with new enough qemu we reject configs which require ACPI, but qemu can't satisfy it. This breaks migration of existing VMs with the old wrong configs to new libvirt installations. To address this introduce a post-parse fixup removing the ACPI flag specifically for s390 machines which do enable it in the definition. The advantage of doing it in post-parse, rather than simply relaxing the ABI stability check to allow users providing an fixed XML when migrating (allowing change of the ACPI flag for s390 in ABI stability check, as it doesn't impact ABI), is that only the destination installation needs to be patched in order to preserve migration. To mitigate the disadvantage of simply stripping it from all s390(x) configs the hack is not applied when defining or starting a new domain from the XML, to preserve the error about unsupported configuration. Resolves: https://issues.redhat.com/browse/RHEL-49516 Signed-off-by: Peter Krempa Reviewed-by: Andrea Bolognani Reviewed-by: Boris Fiuczynski --- src/qemu/qemu_domain.c | 47 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 198ab99aef..a7a34e66e2 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -5020,6 +5020,51 @@ qemuDomainDefPostParseBasic(virDomainDef *def, } +/** + * qemuDomainDefACPIPostParse: + * @def: domain definition + * @qemuCaps: qemu capabilities object + * + * Fixup the use of ACPI flag on certain architectures that never supporte= d it + * and users for some reason used it, which would break migration to newer + * libvirt versions which check whether given machine type supports ACPI. + * + * The fixup is done in post-parse as it's hard to update the ABI stability + * check on source of the migration. + */ +static void +qemuDomainDefACPIPostParse(virDomainDef *def, + virQEMUCaps *qemuCaps, + unsigned int parseFlags) +{ + /* Only cases when ACPI is enabled need to be fixed up */ + if (def->features[VIR_DOMAIN_FEATURE_ACPI] !=3D VIR_TRISTATE_SWITCH_ON) + return; + + /* This fixup is applicable _only_ on architectures which were present= as of + * libvirt-9.2 and *never* supported ACPI. The fixup is currently done= only + * for existing users of s390(x) to fix migration for configs which had + * despite being ignored. + */ + if (def->os.arch !=3D VIR_ARCH_S390 && + def->os.arch !=3D VIR_ARCH_S390X) + return; + + /* Strip the feature only for non-fresh configs, in order to s= till + * produce an error if the feature is present in a newly defined one. + * + * The use of the VIR_DOMAIN_DEF_PARSE_ABI_UPDATE looks counter-intuit= ive, + * but it's used only in qemuDomainCreateXML/qemuDomainDefineXMLFlags = APIs + * */ + if (parseFlags & VIR_DOMAIN_DEF_PARSE_ABI_UPDATE) + return; + + /* To be sure, we only strip ACPI if given machine type doesn't suppor= t it */ + if (virQEMUCapsMachineSupportsACPI(qemuCaps, def->virtType, def->os.ma= chine) =3D=3D VIR_TRISTATE_BOOL_NO) + def->features[VIR_DOMAIN_FEATURE_ACPI] =3D VIR_TRISTATE_SWITCH_ABS= ENT; +} + + static int qemuDomainDefPostParse(virDomainDef *def, unsigned int parseFlags, @@ -5040,6 +5085,8 @@ qemuDomainDefPostParse(virDomainDef *def, if (qemuDomainDefMachinePostParse(def, qemuCaps) < 0) return -1; + qemuDomainDefACPIPostParse(def, qemuCaps, parseFlags); + if (qemuDomainDefBootPostParse(def, driver, parseFlags) < 0) return -1; --=20 2.45.2