From nobody Mon Feb 9 17:59:17 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1768297076; cv=none; d=zohomail.com; s=zohoarc; b=P4wBUYak9TOltvVh7GofBLHwBkCtojuD/dVoKI285P5WxKJwsAzgGHusBTJYE2azTORnnd5qCMi4hOLWnx3/zKspxW1PR6jNPRGhphHgjpwj2yZARmER92EJIM6QN3VK32YB4lKRa4mFpL9iloMzPiWiWo1Q2ILsa69/WnipGQc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1768297076; 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=LLSaEL8hFLNBJUbpGN52yDV/UnUeDG0ybE+dW81ZIPs=; b=cv81ILWdDd7+g2NcvoXl0BD+GhD0PRuxPse/3LDbDwSOwGw5jwhMVU2OWhj/I0cMie9y4FlOMeuBGT6qWlrM+ngJwu1EkyVJC3qQkCHrqKOp/Rfr7OqZ++k/tidhshu0q+Cj2zVRWJb9AwUbcVmzqKbAanXhtkdGqd98jC8LG78= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1768297076123416.613068522445; Tue, 13 Jan 2026 01:37:56 -0800 (PST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1vfaq6-0007Sv-Mn; Tue, 13 Jan 2026 04:37:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1vfaq4-0007Gl-Fu for qemu-devel@nongnu.org; Tue, 13 Jan 2026 04:37:24 -0500 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 1vfaq2-0003KA-Pb for qemu-devel@nongnu.org; Tue, 13 Jan 2026 04:37:24 -0500 Received: from mx-prod-mc-03.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-103-8QTTzXDAN3-NvFgSOY7Bsg-1; Tue, 13 Jan 2026 04:37:18 -0500 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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A73AB1956050; Tue, 13 Jan 2026 09:37:17 +0000 (UTC) Received: from corto.redhat.com (unknown [10.44.32.79]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 76FBF30001A8; Tue, 13 Jan 2026 09:37:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768297042; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LLSaEL8hFLNBJUbpGN52yDV/UnUeDG0ybE+dW81ZIPs=; b=RVrJ1/1Rgv0feRjWTXM0s1RTZz3D+hcqql4nPeUN99yuC5Mn7UUGVIx9EURuFBWbkizTOZ fNDYV+F6LAIUV+H5cX8alTC1n53E7jmLt5r20fM+tkchkW5A/7K5WCQ05WZj8ad0L/DWxF 2xrVqM8aLpPIkwRaWyAHsAVEC//cMGk= X-MC-Unique: 8QTTzXDAN3-NvFgSOY7Bsg-1 X-Mimecast-MFC-AGG-ID: 8QTTzXDAN3-NvFgSOY7Bsg_1768297037 From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= To: qemu-devel@nongnu.org Cc: Alex Williamson , Zhenzhong Duan , Yi Liu , Eric Auger , "Michael S. Tsirkin" , =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Subject: [PULL 12/41] intel_iommu_accel: Fail passthrough device under PCI bridge if x-flts=on Date: Tue, 13 Jan 2026 10:36:08 +0100 Message-ID: <20260113093637.1549214-13-clg@redhat.com> In-Reply-To: <20260113093637.1549214-1-clg@redhat.com> References: <20260113093637.1549214-1-clg@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.129.124; envelope-from=clg@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1768297077642158500 From: Zhenzhong Duan Currently we don't support nested translation for passthrough device with emulated device under same PCI bridge, because they require different addre= ss space when x-flts=3Don. In theory, we do support if devices under same PCI bridge are all passthrou= gh devices. But emulated device can be hotplugged under same bridge. To simpli= fy, just forbid passthrough device under PCI bridge no matter if there is, or w= ill be emulated devices under same bridge. This is acceptable because PCIE brid= ge is more popular than PCI bridge now. Suggested-by: Yi Liu Signed-off-by: Zhenzhong Duan Reviewed-by: Eric Auger Reviewed-by: Yi Liu Reviewed-by: Michael S. Tsirkin Link: https://lore.kernel.org/qemu-devel/20260106061304.314546-11-zhenzhong= .duan@intel.com Signed-off-by: C=C3=A9dric Le Goater --- hw/i386/intel_iommu_accel.h | 4 ++-- hw/i386/intel_iommu.c | 7 ++++--- hw/i386/intel_iommu_accel.c | 12 +++++++++++- 3 files changed, 17 insertions(+), 6 deletions(-) diff --git a/hw/i386/intel_iommu_accel.h b/hw/i386/intel_iommu_accel.h index 79117b25a030a3d22d75b635725a6f78a21ec407..1d1fffb731a0daaf81f283e9967= 07b25738eb5b6 100644 --- a/hw/i386/intel_iommu_accel.h +++ b/hw/i386/intel_iommu_accel.h @@ -13,11 +13,11 @@ #include CONFIG_DEVICES =20 #ifdef CONFIG_VTD_ACCEL -bool vtd_check_hiod_accel(IntelIOMMUState *s, HostIOMMUDevice *hiod, +bool vtd_check_hiod_accel(IntelIOMMUState *s, VTDHostIOMMUDevice *vtd_hiod, Error **errp); #else static inline bool vtd_check_hiod_accel(IntelIOMMUState *s, - HostIOMMUDevice *hiod, + VTDHostIOMMUDevice *vtd_hiod, Error **errp) { error_setg(errp, "host IOMMU cannot be checked!"); diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index b11798d4b75b7fb6961a1b2bde8851667b0d07db..0817b1777220072f6b10e13af73= b1c6434447d1a 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -4570,9 +4570,10 @@ VTDAddressSpace *vtd_find_add_as(IntelIOMMUState *s,= PCIBus *bus, return vtd_dev_as; } =20 -static bool vtd_check_hiod(IntelIOMMUState *s, HostIOMMUDevice *hiod, +static bool vtd_check_hiod(IntelIOMMUState *s, VTDHostIOMMUDevice *vtd_hio= d, Error **errp) { + HostIOMMUDevice *hiod =3D vtd_hiod->hiod; HostIOMMUDeviceClass *hiodc =3D HOST_IOMMU_DEVICE_GET_CLASS(hiod); int ret; =20 @@ -4596,7 +4597,7 @@ static bool vtd_check_hiod(IntelIOMMUState *s, HostIO= MMUDevice *hiod, return true; } =20 - return vtd_check_hiod_accel(s, hiod, errp); + return vtd_check_hiod_accel(s, vtd_hiod, errp); } =20 static bool vtd_dev_set_iommu_device(PCIBus *bus, void *opaque, int devfn, @@ -4632,7 +4633,7 @@ static bool vtd_dev_set_iommu_device(PCIBus *bus, voi= d *opaque, int devfn, vtd_hiod->iommu_state =3D s; vtd_hiod->hiod =3D hiod; =20 - if (!vtd_check_hiod(s, hiod, errp)) { + if (!vtd_check_hiod(s, vtd_hiod, errp)) { g_free(vtd_hiod); vtd_iommu_unlock(s); return false; diff --git a/hw/i386/intel_iommu_accel.c b/hw/i386/intel_iommu_accel.c index 2942eff100b9e7871326d27b58b71517ff705271..99f173b2486c4bd05d6cfeed56d= 03c3efc6a658d 100644 --- a/hw/i386/intel_iommu_accel.c +++ b/hw/i386/intel_iommu_accel.c @@ -12,12 +12,16 @@ #include "system/iommufd.h" #include "intel_iommu_internal.h" #include "intel_iommu_accel.h" +#include "hw/pci/pci_bus.h" =20 -bool vtd_check_hiod_accel(IntelIOMMUState *s, HostIOMMUDevice *hiod, +bool vtd_check_hiod_accel(IntelIOMMUState *s, VTDHostIOMMUDevice *vtd_hiod, Error **errp) { + HostIOMMUDevice *hiod =3D vtd_hiod->hiod; struct HostIOMMUDeviceCaps *caps =3D &hiod->caps; struct iommu_hw_info_vtd *vtd =3D &caps->vendor_caps.vtd; + PCIBus *bus =3D vtd_hiod->bus; + PCIDevice *pdev =3D bus->devices[vtd_hiod->devfn]; =20 if (!object_dynamic_cast(OBJECT(hiod), TYPE_HOST_IOMMU_DEVICE_IOMMUFD)= ) { error_setg(errp, "Need IOMMUFD backend when x-flts=3Don"); @@ -36,6 +40,12 @@ bool vtd_check_hiod_accel(IntelIOMMUState *s, HostIOMMUD= evice *hiod, return false; } =20 + if (pci_device_get_iommu_bus_devfn(pdev, &bus, NULL, NULL)) { + error_setg(errp, "Host device downstream to a PCI bridge is " + "unsupported when x-flts=3Don"); + return false; + } + error_setg(errp, "host IOMMU is incompatible with guest first stage translat= ion"); return false; --=20 2.52.0