From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D2703C988B for ; Fri, 14 Aug 2026 14:15:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786716974; cv=none; b=qmP610FoNIiTFtwitTORGvIcUDzcZtxmPx6nq8ZOKgiedCrzJT5GTe8v+QAL/Uk9n6xV3+qVSFtd3BJja232b5KyQ3Xp/9phWcabFlTy4rmL/DtnnN4cGvKIV4XYDDJLo7RwT8qRBa7NCX7Mqd5G6UHxJ6bRpjGVAcZ8NGqCjT8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786716974; c=relaxed/simple; bh=wNpmRG0bvwI0zH3SDqeNYVrQrLdnvlPl+nuh3Ab+P20=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lnIwsGuYHiP6N1L1AVkpo2e+wM+dRXKQuz6wdfdskgqVCt6gqSZl1Mo9TsE/Au2C+dWDQvWupMwJgB36WInqIYYhThKJg4n4LVXdEAkx/rtdHYxnTo62BN8LVI9XH6QxpvYx5BcRiSXLXu2G5xOcK+ICfoLRaL1iLMjp6F5f2U4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=kg2efFP/; arc=none smtp.client-ip=209.85.214.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="kg2efFP/" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2d3b440b97aso89745ad.1 for ; Fri, 14 Aug 2026 07:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786716953; x=1787321753; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=rH19XpzJqW08+W7mG+VpaQ4KF0ayb7gJPWy2w+2WSfo=; b=kg2efFP/TtCo76QCoUbohIN1VPgDDwx85UcEjleCkINT7vo9PAgTqinR/tAwN+VcRv ZNqv4SHT91ZC6/2u5s9WnhxMjVPh9dn/qWsPQqFJH2QycEzCQbPMSbL6rZR9hnWcL8pp Xn8rNxPZa4bgT3iSqy4/iFShecuegYXcIG0vnC2OqQWbH7k8waS6CsGaRTz1KwIauS4W u7kPCNrY0jbX2esOfaeA8/A5svsl3H4FvASxyUdkGeOxUKSORya6K6dE18Yf38nvb0ub 4QeByCY4StcNfGhyJpTGXfBDTA1VS0aiHn1lR68D6mQOSiqDpMkFchN7Tp4os5/KqS04 jVNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786716953; x=1787321753; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=rH19XpzJqW08+W7mG+VpaQ4KF0ayb7gJPWy2w+2WSfo=; b=bQ0vIR9F+YfimfvRZH6zQfh0fil3YpGFAIcAX8usmzPG4wLBl1cKqlvOwFUbPLyTmD 4vQEU1jrH7DfNJOzKUl/aH50peBzT6oAfwxG7Vv6J1R+3tSB0PQ9omENmKLl2uKl+i1/ rujfaHbJokvJXA2pvMu1WWMPgPSjWFMtfXA4vXyjJ23n9mHIKWZ1VNA8z9nUTz+JWRR1 rJjyrNBT2n4MN6B3nS/6YVM9Zj+6r5f6dZZ+8wSzxs2Pg4k5p0/n/qm+Ke212DQnA3nX j51ID0e0QbQrrGs3neim5ycJwk+Vaqw4xhCYqqLiR7N63kn5WDtX14krwElXUBn93gx4 mvJQ== X-Forwarded-Encrypted: i=1; AHgh+RoXEFsQbceGhFDKkiT0MDHxgbTG6b1ElpzisCadgWRKdTRK7X1Gm+r+kqA8hXhhaaUG+mcrFzZLq+zwanM=@vger.kernel.org X-Gm-Message-State: AOJu0YzDpdVNkdQEcqgdLpjDXeJouWWqfaTBX8rsIf8VuBlNhKeVZE2s fJsInFntWiL86JatIeUcLNc1zaIPKuoJHyWzJiomUa+DGek1v8USRVDMqaHZuWg6rw== X-Gm-Gg: AR+sD10XsnGgwDeYwpjRfLFSnwHAv3RroT9519lehC/xhItUuARZgYm6JY4BNu9mX1h HPV2YXo8jh1LmL5n68aN52ghtnHk1AoUt0sFDp0umidFJOEWLB3mwWoVyUhYXsRruch7XHHm29J uN4qHUgfKx6laLgt3Oon+3KMg6RXoc6qLdUzy515a15FU2YD+bx5XiHlUIXNcuwAyK34DC2wv+f dah62MSlvVx6QtHRWvUK4FrMaeVcoCYFURioLmsLoSL6V+xoNWh4sZN/yAo2+W3jOpdzGnWneV3 ogFlRaM/82yWxmPKyxw+3xPylUSIGNLTuuJQVjR9w4r3ZLpQLKD3AT6fZwMWdMoW3asLalggxQF qm8ohsIIjHcKJe2z6e608Xthemrjl1aGsy+IxioPFH1cFHhF9dvQ4PPddA1deNEz3eEcLNn+54G 92Q1k1/YzlMfVTJ1axia0eG580gm3XphkZVZL0vgP+3XUWYqT20PPYZ/VHNGGc+z8w2nplt58+i S1NzuMLX+WmiIgbgKUQvWIQEmGUpzGsNQ== X-Received: by 2002:a17:903:15c8:b0:2ca:6bf:5bac with SMTP id d9443c01a7336-2d3af24fa75mr9130205ad.8.1786716952002; Fri, 14 Aug 2026 07:15:52 -0700 (PDT) Received: from google.com (21.168.124.34.bc.googleusercontent.com. [34.124.168.21]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8517d223f8csm551513b3a.35.2026.08.14.07.15.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 07:15:50 -0700 (PDT) Date: Fri, 14 Aug 2026 14:15:45 +0000 From: Pranjal Shrivastava To: Dmitry Malkin Cc: Will Deacon , Robin Murphy , Joerg Roedel , Nicolin Chen , Jason Gunthorpe , "iommu@lists.linux.dev" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "regressions@lists.linux.dev" , "stable@vger.kernel.org" Subject: Re: [RFC PATCH] iommu/arm-smmu-v3: Allow nested attach for PCI bridges without vDEVICE Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Aug 14, 2026 at 10:07:09AM +0000, Dmitry Malkin wrote: Hi Dmitry, [...] > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c > @@ -5,6 +5,8 @@ > > #include > > +#include > + > #include "arm-smmu-v3.h" > > void *arm_smmu_hw_info(struct device *dev, u32 *length, > @@ -118,6 +120,17 @@ int arm_smmu_attach_prepare_vmaster(struct arm_smmu_attach_state *state, > if (cfg == STRTAB_STE_0_CFG_ABORT || > cfg == STRTAB_STE_0_CFG_BYPASS) > return 0; > + /* > + * Group-wide domain attachment also visits host PCI bridges. Such a > + * bridge is not exposed to the VM and therefore has no virtual SID. > + */ > + if (dev_is_pci(state->master->dev) && > + pci_is_bridge(to_pci_dev(state->master->dev))) { > + dev_info_ratelimited(state->master->dev, > + "skipping vDEVICE requirement for translated nested domain: cfg=%u ret=%d\n", > + cfg, ret); > + return 0; > + } > return ret; > } I agree that this is needed for old bridges. However, should this check actually live higher up in IOMMUFD? Instead of the SMMU driver deciding to bypass the error, what if iommufd itself intercepts the vDEVICE mapping failure during the group iteration? If IOMMUFD sees that the device lacking a vDEVICE is an IOMMU group alias/bridge, it could explicitly tell the underlying driver to proceed with a NULL vmaster? Also, regarding RID aliasing: while it's true the host bridge doesn't need a vDEVICE for its own host-consumed DMAs (like AER/PME), are we confident this won't break guest-injected events if the bridge aliases the downstream endpoint's traffic? For e.g. if the "real" endpoint's traffic is aliased to the bridge's RID and the bridge has no vmaster, won't we lose the ability to inject IO Page faults into the guest? Thanks, Praan