From nobody Sun Apr 28 21:34:25 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1503587568908800.5405065432298; Thu, 24 Aug 2017 08:12:48 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 96A9C8765C; Thu, 24 Aug 2017 15:12:46 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6962D7E233; Thu, 24 Aug 2017 15:12:46 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 32CA81806108; Thu, 24 Aug 2017 15:12:46 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id v7OFCPf5012678 for ; Thu, 24 Aug 2017 11:12:25 -0400 Received: by smtp.corp.redhat.com (Postfix) id 23EF8177E1; Thu, 24 Aug 2017 15:12:25 +0000 (UTC) Received: from inaba.usersys.redhat.com (unknown [10.43.2.219]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9E7BE6375D for ; Thu, 24 Aug 2017 15:12:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 96A9C8765C Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=libvir-list-bounces@redhat.com From: Andrea Bolognani To: libvir-list@redhat.com Date: Thu, 24 Aug 2017 17:12:20 +0200 Message-Id: <20170824151220.23599-1-abologna@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] qemu: Prevent isolation group-related guest disappearance X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 24 Aug 2017 15:12:47 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" We can't retrieve the isolation group of a device that's not present in the system. However, it's very common for VFs to be created late in the boot, so they might not be present yet when libvirtd starts, which would cause the guests using them to disappear. If a PCI address has already been set for the host device in question, we can assume that it either existed at some point in the past or the user is assigning addresses manually: in both cases, we should not error out and just ignore the (temporary) failure. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=3D1484254 Signed-off-by: Andrea Bolognani --- src/qemu/qemu_domain_address.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index 16bf0cdf9..7f12f186b 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -1012,6 +1012,18 @@ qemuDomainFillDeviceIsolationGroup(virDomainDefPtr d= ef, tmp =3D virPCIDeviceAddressGetIOMMUGroupNum(hostAddr); =20 if (tmp < 0) { + /* If there's already a PCI address assigned to the device + * we move on instead of erroring out. + * + * This means we still don't allow non-existing host + * devices to be assigned to guests; however, if the host + * device existed at some point in the past but no longer + * does, which can happen very easily when dealing with VFs, + * we prevent the guest from disappearing and give the user + * an opportunity to edit its configuration */ + if (virDeviceInfoPCIAddressPresent(info)) + goto skip; + virReportError(VIR_ERR_INTERNAL_ERROR, _("Can't look up isolation group for host devic= e " "%04x:%02x:%02x.%x"), --=20 2.13.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list