All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Pecio <michal.pecio@gmail.com>
To: Desnes Nunes <desnesn@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	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
Date: Thu, 18 Jun 2026 06:46:21 +0200	[thread overview]
Message-ID: <20260618064621.01217209.michal.pecio@gmail.com> (raw)
In-Reply-To: <CACaw+ewuPm-eOACKX3Ux0UwJBRSftoBm7H+rxE2Z9E7KzWb5ew@mail.gmail.com>

On Wed, 17 Jun 2026 21:57:02 -0300, Desnes Nunes wrote:
> Hello IOMMU mailing list,
> 
> On Wed, Jun 10, 2026 at 12:32 PM Desnes Nunes <desnesn@redhat.com> wrote:
> >
> > I have just found out the solution for the bug.
> >  
> ...
> > In scalable mode, a PCI bus may populate only the upper root half
> > (UCTP) when all devices on that bus have devfn >= 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=0 and
> > hi=UCTP 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=0x80. 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=0, hi=P) are
> > installed into the upper root half.  
> 
> 0001-iommu-vt-d-Fix-UCTP-context-table-slot-when-copying-.rfc.patch
> 
> > I am doing some final tests now, but since this was a lot to digest,
> > comments at this stage will be most appreciated.  
> 
> FYI, all of my last tests looked OK.
> 
> > To IOMMU maintainers: should I send this patch to the iommu mailing
> > list and move the discussion there?  
> 
> 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

      reply	other threads:[~2026-06-18  4:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-30  1:48 [PATCH] usb: xhci: bound wait command completion to avoid kdump deadlock Desnes Nunes
2026-04-30  8:48 ` Michal Pecio
2026-04-30 17:27   ` Desnes Nunes
2026-04-30 21:54     ` Michal Pecio
2026-05-01 14:09       ` Desnes Nunes
2026-05-02  9:46         ` [PATCH RFT RFC] usb: xhci: Kill hosts with HCE or HSE on command timeout Michal Pecio
2026-05-02 11:38           ` Desnes Nunes
2026-05-02 21:55             ` Michal Pecio
2026-05-03  3:36               ` Desnes Nunes
2026-05-03  5:17                 ` Michal Pecio
2026-05-03 16:20                   ` Desnes Nunes
2026-05-03 19:31                     ` Michal Pecio
2026-05-04  7:31                       ` Michal Pecio
2026-05-18  6:33                         ` Michal Pecio
2026-05-20  4:59                           ` Desnes Nunes
2026-05-22  9:03                             ` Michal Pecio
2026-05-22 20:45                               ` Desnes Nunes
2026-05-23  0:29                                 ` Michal Pecio
2026-05-23  3:47                                   ` Desnes Nunes
2026-05-23  8:28                                     ` Michal Pecio
2026-05-27  3:47                                       ` Desnes Nunes
2026-05-27  8:32                                         ` Michal Pecio
2026-06-10 15:32                                           ` Desnes Nunes
2026-06-18  0:57                                             ` Desnes Nunes
2026-06-18  4:46                                               ` Michal Pecio [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260618064621.01217209.michal.pecio@gmail.com \
    --to=michal.pecio@gmail.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=desnesn@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=iommu@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.