From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 0F9E546AF25 for ; Thu, 7 May 2026 19:21:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778181708; cv=none; b=YWhZYSsi1RYmOtTiGY0hFQE7SIAXceC+mO9BKGtAFGvPWQX6RvzVQs0gxFooU2DgzrP4mxGMoHn9h43sGH52UVM5T8H6RxHj9NdHLxwKHmZx6ybVVB6OjyyO+eXxyoetFU7Jp2o54RCl19io6fhBWTbv3FleFRJRf0G87SSzD2E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778181708; c=relaxed/simple; bh=bV79z0tqnwrOM2+SY76sjwiQQcenUZEz3fZIwF06ZXM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=J3g5uBwVVeaKazyZB/hPEBkxTPCEllulK+bEdIjvwkZBWXPfWNdEbINEhFCl636vpPKrUzdW638WGueMnLPoHm/vcKKHsGl06GHF9RAP7IQBp8MpKHH1IQ6Ec8U/rwqn79zWAcxgfJgZcEy8tryc/Dii8xha1CE128GQB9NEPxc= 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=CXX/9prH; arc=none smtp.client-ip=209.85.214.179 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="CXX/9prH" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2b46da8c48eso129835ad.1 for ; Thu, 07 May 2026 12:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778181706; x=1778786506; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=urgZfwF4+fq0Bvx57GpO772zcrt3WJsYUh542YPK0gU=; b=CXX/9prHG1oTVPng6mbM6OsBBzxWLgx5/+VPiWmxEIcXOPLfIb5mDDlejirkaqeiKC bAvFCgeWTiJDlAryk4hiWTH5czHLSWE6FUOEeg040UaUPNPMMf7OFUBjr3XFXtYt9xwa XanE7fiVFuZwWogKy+Mm8PhpwHL8QIK9CZTXF5H2VqEpkKokCuMZk1808boxltuJPHQB TD0hkcCq6CweiE8AvdNfpdD1GZKRukD4XK1PCsCrA7rDYB7aGHplmReYouysnj2bQ+it XtGmNlFd7GeJoCPYzYtzVJFeXzT8GjVXEYCBCYqtEurJBa+yK+G/CLG9v+Nre8+arLIz Lt7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778181706; x=1778786506; h=in-reply-to:content-disposition: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; bh=urgZfwF4+fq0Bvx57GpO772zcrt3WJsYUh542YPK0gU=; b=f0OxxuYbWdePXPL5LeAPgcatYhpdM/b4+r3CgV0e4aOQ73BdyQLQwq5VaeP0ljn6MS QbpWu5La+kDNYmAFZc+hDbxzbYEYVIkyObr7kX237vhi3dNPc2c2KqpqPsnII2cjun+W jHIz2ZkQ2/tdLOPCYjtJCeAU9xiJEeUdXabTmlAHrNohCLf2zhaDD9xgNs0lDK0GvDkj 8ouwbcUnMQbIOS7jzvivjQ2SyaDSsAqtM5lTSSR80CDhooB4UQ/wSQ6l1DPwmyEfRDr8 KB8QuVRl3SFrpMsKVwY7Q+XFGNooz/TJSgBMBDKEWtEaQJOGH9h1yEWCtj37E1b1qQmH ijWw== X-Forwarded-Encrypted: i=1; AFNElJ+x2FX1s3ToQi7wZyBrgIdSAKp2U9JYkzKfKyfmrnWmqM5FmXhkJtCOFgHbO+FSj4PKdIlaDLlcRrN+Oy0=@vger.kernel.org X-Gm-Message-State: AOJu0YxOBxQWzTySxfBmENQoTnSF+L7YBzonvONuKBMF4xXOCRS9rRB/ Fxj288QNTRPT+q7MZbQiQ4ui4olrB/CPABEL+RdV7FDBwwZ2hZ8FTDo48y+KAzZH1Q== X-Gm-Gg: Acq92OGJ6jCz9Ul2KrdMevYEKeq8NKzA1zCb8Khdu0hl11udy3csmramaRIeytvUBg7 nG5j9aQywTJkInCQ8viTWAIlp42jl1m+Qb/DsswZTrAfrLp6mSagPr1TOurYgiXLAcBwDcRcvAw TTEBoc9oWMv4kfBBHvJ/7F1WeA9isX0tSbL6/ZN07DDVUCVf9VXjIpl0Mbq4lpe1Db+0POUhWF0 8lXlIRNY4dL9SRehrvRm7lEaZlVoa+lTe/w/0emCb6j2CVwXi5wPPcE0lc3RjgNHSmeE/XYHObB uft3fXmVj7K01bsIbl+czYjD6wYx9+30AsSEq+sXtbOspPJARC9pdRhjlBXVqhSjZchpSrrgtR+ 87i4Paa8tZKmPQf3qriB9GOHpnbjG3sX/wL3a6WH/R+ldXAFTTwZq1RYcu4c/y54mrptt18Pni2 E3IbUlduuKpD/bSdHLIM/YQ6VzhzhdlCQrUE5S/d9zgYWPVdFm0FSj/afdh+/1fV8ZeFUI X-Received: by 2002:a17:903:3c6d:b0:2b2:70ba:305c with SMTP id d9443c01a7336-2bae9a8bf41mr779895ad.8.1778181705676; Thu, 07 May 2026 12:21:45 -0700 (PDT) Received: from google.com (44.234.124.34.bc.googleusercontent.com. [34.124.234.44]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3664735c942sm213564a91.1.2026.05.07.12.21.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 May 2026 12:21:45 -0700 (PDT) Date: Thu, 7 May 2026 19:21:39 +0000 From: Pranjal Shrivastava To: Yigit Oguz Cc: joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, baolu.lu@linux.intel.com, dwmw2@infradead.org, suravee.suthikulpanit@amd.com, jgg@ziepe.ca, nicolinc@nvidia.com, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Lilit Janpoladyan Subject: Re: [PATCH 2/3] iommu/vt-d: Add PCI segment and vendor:device ID to DMAR fault logs Message-ID: References: <20260506150541.60467-1-yigitogu@amazon.de> <20260506150541.60467-3-yigitogu@amazon.de> 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: <20260506150541.60467-3-yigitogu@amazon.de> On Wed, May 06, 2026 at 03:05:38PM +0000, Yigit Oguz wrote: > Include the full SSSS:BB:DD.F address with PCI segment and > vendor:device ID (VVVV:DDDD) in DMAR fault messages. Uses > iommu->segment for the PCI domain and pci_get_domain_bus_and_slot > to look up the pci_dev. Falls back to segment:BDF without > vendor:device if the device is not found. > > This brings Intel IOMMU fault logging in line with the ARM SMMUv3 > event decoding, making it easier to identify faulting devices > (e.g. after FLR) without cross-referencing lspci. > > Before: > DMAR: [DMA Write NO_PASID] Request device [86:00.0] fault addr 0xe0000000 > [fault reason 0x05] PTE Write access is not set > > After: > DMAR: [DMA Write NO_PASID] Request device [0000:86:00.0 8086:1533] fault addr 0xe0000000 > [fault reason 0x05] PTE Write access is not set > > Signed-off-by: Yigit Oguz > Signed-off-by: Lilit Janpoladyan > Assisted-by: Claude:claude-4.6-opus > --- > drivers/iommu/intel/dmar.c | 33 +++++++++++++++++++++------------ > 1 file changed, 21 insertions(+), 12 deletions(-) > > diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c > index d33c119a935e..225fa498d714 100644 > --- a/drivers/iommu/intel/dmar.c > +++ b/drivers/iommu/intel/dmar.c > @@ -1890,30 +1890,39 @@ static int dmar_fault_do_one(struct intel_iommu *iommu, int type, > { > const char *reason; > int fault_type; > + u8 bus = source_id >> 8; > + u8 devfn = source_id & 0xFF; > + struct pci_dev *pdev; > + char devid[48]; Why not have a #define for this like you have for AMD and Arm? > > reason = dmar_get_fault_reason(fault_reason, &fault_type); > > + pdev = pci_get_domain_bus_and_slot(iommu->segment, bus, devfn); Not an Intel iommu expert, but I have concerns about using pci_get_domain_bus_and_slot() in this path. AFAICT, dmar_fault_do_one() is running in a IRQ context & the pci_get_* family of functions iterates the global PCI klist. It eventually calls bus_to_subsys(), which takes a plain spin_lock(&bus_kset->list_lock) [1] which isn't IRQ-safe. Same thing with klist_put [2] called in klist_iter_exit > + if (pdev) { > + snprintf(devid, sizeof(devid), "%04x:%02x:%02x.%d %04x:%04x", > + iommu->segment, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), > + pdev->vendor, pdev->device); > + pci_dev_put(pdev); Same here, pci_dev_put call put_device which might sleep [3] and hence shouldn't be called in hard IRQ context. > + } else { > + snprintf(devid, sizeof(devid), "%04x:%02x:%02x.%d", > + iommu->segment, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > + } > + > if (fault_type == INTR_REMAP) { > - pr_err("[INTR-REMAP] Request device [%02x:%02x.%d] fault index 0x%llx [fault reason 0x%02x] %s\n", > - source_id >> 8, PCI_SLOT(source_id & 0xFF), > - PCI_FUNC(source_id & 0xFF), addr >> 48, > - fault_reason, reason); > + pr_err("[INTR-REMAP] Request device [%s] fault index 0x%llx [fault reason 0x%02x] %s\n", > + devid, addr >> 48, fault_reason, reason); > > return 0; > } > [-------------- >8 -------------------] Thanks, Praan [1] https://elixir.bootlin.com/linux/v7.0.1/source/drivers/base/bus.c#L60 [2] https://elixir.bootlin.com/linux/v7.0.1/source/lib/klist.c#L209 [3] https://elixir.bootlin.com/linux/v7.0.1/source/drivers/base/core.c#L3794