From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 8889A28725A for ; Thu, 18 Jun 2026 04:46:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781757988; cv=none; b=HeM3oANSIZNFowVT+popTepKnrfBCVRFtkzMOo/IGr3NBvmkjYdvQ/8TfXy1Dy9yqCPxuWM21xGMtK2yfC5TUSG0gYfhmHJkkmKfrV2yMnTH3/NMiDbek5R3EU5wG6nkO5c5YdOpBj/xM4tJIsPKlnoJWtN/jCI9t6g5QtQu9Eo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781757988; c=relaxed/simple; bh=ip04cpuJ6gZcMJKZUo/58OpvKcONH5fc81aL2U5VDTU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Geu6WxvN3VuTjtOut5fMPERoig8IHHQjpoImKnWgbD2gt3ANt/dlTTsKLHkQACxBR7Xa4pH8z5vr2Ea45n+n7Cz8i233Zdm5RUF6/OW8mRyvgdGlDbv0j5Pumeoh9xKdNbAkn1yknuvXQexRdnuHvCQ7ZnJLTDqRMwJShd2M5Xg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=fv/1urIo; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fv/1urIo" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-490cdae130cso1833505e9.0 for ; Wed, 17 Jun 2026 21:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781757986; x=1782362786; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=P2406RcRfSwFwzqOnhnwujT4ewtnrCh+0Xd1gHWd5a4=; b=fv/1urIoRFzw1+c5+quRncujEA7ZIby/KMaL4roCUxUMtPUzfP56t4tmLZTmOvcZOj 8/lM4Earcxaxm+LUAT0V0i3PaiZRrByZfneMVMgC3nOoHohCfhGA39nkY0hNLLHIUTks K7bSxhyVhBLQR1UnsFj1kYBq3XBJgQl9+9MpeUVo2CJCmK6ztAV637gP2lJTGjmMwzSb QL+ZVKmVfO7RDaNTmWp4bJIQTlBVz8rrHNzWzQmAG6NkD1Q6BGRGocyMPUlNO4U3hk8p 4Y8c5MAhnEqz/hg5AKLGDq6Q/1kJqKuWWYliIYVS2mu0LFcyGhwQQHCmGjN3V1S6/JZV xDUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781757986; x=1782362786; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=P2406RcRfSwFwzqOnhnwujT4ewtnrCh+0Xd1gHWd5a4=; b=KfQp6E22pw6UKMLubH00eXjzdAcJDAhv3SgT4cuPdKfxj3HnNF8Ha5H7jY4KALaOZI pAJ3uSDdTIinmDoM7+bP1pL2/IwCTHtaVcuLGXZ+GfeQdG9b+k1sumzaInRdavmMwh8b A/kvtvIm/5ldmm+rCgMjVnhlL6vEOS6TUxeX6T+MOXSdcH4IXyXkYprqDkDCDFOp9Ke0 bqxtolP/6Fp4p8cGz0muVseQeusvEXzcJBzzVsUVSa/JIiYsiRLMgxZrP5CrVrKQpoWV iY7Sab6qGuXgpYhJuE/lTMfw/2JvvDHodbRu5oTbB8n/6vWEZABi1F0Hs3lAFmAdQYjC 8FDA== X-Forwarded-Encrypted: i=1; AFNElJ+wsoB7s+d7IGVpOJWI4RFQ/9FdBCaTKGFOlzSkfdjyWw7wFx3qvuGxHBeu4+2aQfr8+k1YYpNMQ3MqK/M=@vger.kernel.org X-Gm-Message-State: AOJu0YzAHFpMOYmf92jqcFml/m1VSkwBdA2rBUJmyngGR7Z3EocApXRC RaRO1aZdDhtzxD6+afKHwlEIXjpNGlJt2jQlFOZDkP3GUP2TkIrLsRsk X-Gm-Gg: Acq92OHATAwiqSpLFS/nr+CbW746fiI6/iKRJ0V8Gh4REjtAapvHykoqSLfgxGUy7Cy K8Dw/X2KSLX/fSlG4p7FYp6T383PJdXPo0CyiyOZz3He52SaoMfsq7NwmypL+32AWhCivzQEWT2 g5Ad+52cHM7lr4nMh8nC3ChHL2e4Tm7g+iZsJqcQ16eNIludJgzr/awSmMCuTr81+qjhyJMYKEa GmWRIPQHF69es0aNZY+zICbjxKThm5QvbrAJL9UBNxHO+yumbP2BRtMdoV2e9Srf1DxZ/Ze068R ViDw91qIwdbx6lIkuF6ERuvTj0l5vsyPRXXB5Gj9FadGQ51ZFSKWaDAEDH1CbPe1CDIT89POe7r 1KDKlGyYU1+/qj5GuLsnPE6FQN451vl5Pqu794rinJkwbKHxfCl/JVLlvuzWTWUODtKLxPMTzvc 0dYIoYKF3USHZwFbHmnSxzKg== X-Received: by 2002:a05:600c:4fcf:b0:490:c024:2ec8 with SMTP id 5b1f17b1804b1-4923819e3f0mr31138725e9.0.1781757985830; Wed, 17 Jun 2026 21:46:25 -0700 (PDT) Received: from foxbook (bfg19.neoplus.adsl.tpnet.pl. [83.28.44.19]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4923a1d585esm19139325e9.2.2026.06.17.21.46.24 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 17 Jun 2026 21:46:25 -0700 (PDT) Date: Thu, 18 Jun 2026 06:46:21 +0200 From: Michal Pecio To: Desnes Nunes Cc: David Woodhouse , Lu Baolu , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, gregkh@linuxfoundation.org, mathias.nyman@intel.com, stable@vger.kernel.org, iommu@lists.linux.dev Subject: Re: Intel IOMMU bug: xHCI faults during crash kernel boot Message-ID: <20260618064621.01217209.michal.pecio@gmail.com> In-Reply-To: References: <20260430014817.2006885-1-desnesn@redhat.com> <20260503071749.6abda137.michal.pecio@gmail.com> <20260503213111.117db3a1.michal.pecio@gmail.com> <20260504093118.615ff480.michal.pecio@gmail.com> <20260518083339.507e24bd.michal.pecio@gmail.com> <20260522110328.0d3eecd8.michal.pecio@gmail.com> <20260523022944.59799d83.michal.pecio@gmail.com> <20260523102815.5c05c70a.michal.pecio@gmail.com> <20260527103221.7f8b15b0.michal.pecio@gmail.com> 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=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 17 Jun 2026 21:57:02 -0300, Desnes Nunes wrote: > Hello IOMMU mailing list, >=20 > On Wed, Jun 10, 2026 at 12:32=E2=80=AFPM Desnes Nunes wrote: > > > > I have just found out the solution for the bug. > > =20 > ... > > In scalable mode, a PCI bus may populate only the upper root half > > (UCTP) when all devices on that bus have devfn >=3D 0x80. On bus > > 0x80, I have e1000e at 80:1f.6 (devfn 0xfe) and xHCI at 80:14.0 > > (devfn 0xa0), so the hardware root entry correctly has lo=3D0 and > > hi=3DUCTP present. > > > > However, after copy_translation_tables(), I noticed that > > root[128].hi was zeroed-out (Present bit cleared) and another > > (expected) different value on root[128].lo. > > > > In short, the culprit here is having a zeroed LCTP, since at > > copy_context_table() the allocation of new_ce for LCTP context > > entries currently governs the pos variable; which is later used to > > save new_ce entries for UCTP at tbl[tbl + pos]. > > On the first iteration idx will be zero, old_ce_phys will be empty, > > thus this moves the loop straight to devfn=3D0x80. At devfn 0x80, idx > > wraps to 0 again ( (devfn * 2) mod 256), but since no new_ce was > > previouly allocated for LCTP context entries, pos will remain zero > > while copying UCTP context entries. After all upper context entries > > are saved, tbl will receive new_ce from UCTP at tbl[tbl_idx + 0], > > and not tbl[tbl_idx + 1]. These will be later written in > > copy_translation_tables() to iommu->root_entry[bus].lo and > > iommu->root_entry[bus].hi, which causes the bug. > > > > In summary, the hardware tables were correct, but the copy path > > misplaced the UCTP table for bus 0x80 when dealing with a LCTP > > zeroed-out during kdump. > > > > To fix this, I created a v3 patch that uses devfn to better track > > which half we are copying, so UCTP-only buses (lo=3D0, hi=3DP) are > > installed into the upper root half. =20 >=20 > 0001-iommu-vt-d-Fix-UCTP-context-table-slot-when-copying-.rfc.patch >=20 > > I am doing some final tests now, but since this was a lot to digest, > > comments at this stage will be most appreciated. =20 >=20 > FYI, all of my last tests looked OK. >=20 > > To IOMMU maintainers: should I send this patch to the iommu mailing > > list and move the discussion there? =20 >=20 > I meant as a new submission to IOMMU maling list, since this started > in xHCI at the usb mailing list. > Of course, that is if nobody has any comments or objections to the > patch. Looks like no one from IOMMU pays much attention in the first place. Let's see if a subject change helps. If you have a working patch which fixes this, just submit it following usual rules in Documentation/process/submitting-patches.rst. Regards, Michal