From nobody Mon Feb 9 01:00:53 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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.133.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=1674831968; cv=none; d=zohomail.com; s=zohoarc; b=h+AWYiyHDK2XBGQbIBP7E2xPOowmCK269PcIAyz4+ysaV5Maq7I46k9TpWE/2zFZnAtbHX1rW8remtGCvUQLfcOVXVJPX9VLB2+OUqum/XNX1eEB+HsjVGsP1kUefP5xqOoClpYUQDZ0terjKdqsqgpqwYD+6QrW0KP7O6vbtHk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1674831968; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=/PA++QDIjQp8yiHK0tFAa8HRl00mfpJZOJUfaTE5McQ=; b=XdwWjvEXULjQTeHfgSrj0+H1n45HxbGOqg3KCph6PervEOukHJuWVwWkdI8r57KI/GuEHk8B3Jns3DAKgzdNoa4zCzKLoycWDvhWWKxQa+RNiuKX4b1RPXCcLTblntFVFSntep2rtVFdCrdTZe/s36+jaPUKb3w8JdsrWVFCsDM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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.133.124]) by mx.zohomail.com with SMTPS id 1674831968389674.1674016117947; Fri, 27 Jan 2023 07:06:08 -0800 (PST) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-557-u4bSDtmjPJWqOXpiWw7ONg-1; Fri, 27 Jan 2023 10:05:20 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 14431857A89; Fri, 27 Jan 2023 15:05:14 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id AD7572026D4B; Fri, 27 Jan 2023 15:05:13 +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 5439D194658D; Fri, 27 Jan 2023 15:05:13 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 43D8F19465B7 for ; Fri, 27 Jan 2023 15:05:12 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 2766B7AD4; Fri, 27 Jan 2023 15:05:12 +0000 (UTC) Received: from maggie.redhat.com (unknown [10.43.2.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id C34BB18EC1 for ; Fri, 27 Jan 2023 15:05:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674831967; h=from:from:sender:sender: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:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=/PA++QDIjQp8yiHK0tFAa8HRl00mfpJZOJUfaTE5McQ=; b=PhsqNpcYQbACgSmG7u7kywhWpbguzJiHS+o7OOKHBB68XOEyTDVczOpCmhQ/ySu8Btt4bT UozGs7IIRiqx1VwXxD3Yoadj3JLxmjkN/pyeklx3H6QmnRmQTDcE2F9/umuNp+DaLub780 5fmMBNspr3Nc/pCCnA3J3z+t4TF3VKs= X-MC-Unique: u4bSDtmjPJWqOXpiWw7ONg-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH 3/3] qemuProcessLaunch: Tighten rules for external devices wrt incoming migration Date: Fri, 27 Jan 2023 16:05:08 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 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: , Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 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: 1674831968870100001 Content-Type: text/plain; charset="utf-8"; x-default="true" When starting a guest, helper processes are started first. But they need a bit of special handling. Just consider a regular cold boot and an incoming migration. For instance, in case of swtpm with its state on a shared volume, we want to set label on the state for the cold boot case, but don't want to touch the label in case of incoming migration (because the source very specifically did not restore it either). Until now, these two cases were differentiated by testing @incoming against NULL. And while that makes sense for other aspects of domain startup, for external devices we need a bit more, because a restore from a save file is also 'incoming migration'. Now, there is a difference between regular migration and restore from a save file. In the former case we do not want to set seclabels in the save state. BUT, in the latter case we do need to set them, because the code that saves the machine restored seclabels. Signed-off-by: Michal Privoznik --- src/qemu/qemu_process.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 6718915293..f9789650bc 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -7621,6 +7621,7 @@ qemuProcessLaunch(virConnectPtr conn, size_t nnicindexes =3D 0; g_autofree int *nicindexes =3D NULL; unsigned long long maxMemLock =3D 0; + bool incomingMigrationExtDevices =3D false; =20 VIR_DEBUG("conn=3D%p driver=3D%p vm=3D%p name=3D%s id=3D%d asyncJob=3D= %d " "incoming.uri=3D%s " @@ -7675,7 +7676,13 @@ qemuProcessLaunch(virConnectPtr conn, if (qemuDomainSchedCoreStart(cfg, vm) < 0) goto cleanup; =20 - if (qemuExtDevicesStart(driver, vm, incoming !=3D NULL) < 0) + /* For external devices the rules of incoming migration are a bit stri= cter, + * than plain @incoming !=3D NULL. They need to differentiate between + * incoming migration and restore from a save file. */ + incomingMigrationExtDevices =3D incoming && + vmop =3D=3D VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_START; + + if (qemuExtDevicesStart(driver, vm, incomingMigrationExtDevices) < 0) goto cleanup; =20 if (!(cmd =3D qemuBuildCommandLine(vm, --=20 2.39.1