linux-kernel - Re: [PATCH v16 0/3] Avoid PCIe D3 for AMD PCIe root ports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <29ad9d0b-ccb7-49d4-a712-53bef5c73181@amd.com>
Date:   Wed, 6 Sep 2023 08:38:02 -0500
From:   Mario Limonciello <mario.limonciello@....com>
To:     Hans de Goede <hdegoede@...hat.com>, bhelgaas@...gle.com,
        rafael@...nel.org, Shyam-sundar.S-k@....com
Cc:     linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
        platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH v16 0/3] Avoid PCIe D3 for AMD PCIe root ports

On 9/6/2023 07:24, Hans de Goede wrote:
> 
> "XHCI tunneling" is an unfamiliar term for me. Are we talking about a XHCI controller inside a USB4/thunderbold dock here which is connected to the laptop over PCIe tunneling over thunderbolt ?
> 
> Or do you mean the XHCI controller inside the laptop which is connected to a USB4/thunderbolt capable Type-C port which is used when that port is in USB3/USB2 mode ?
> 
> As long as the XHCI controller is inside the laptop (and not in the dock), presumably you can identify it by say a set of PCI device-ids of the "tunneling" XHCI controllers on affected AMD platforms. So you could then still call pci_d3cold_disable() from the XHCI driver on only those controllers.

XHCI tunneling refers to XHCI over USB4 fabric.   The problem isn't with 
the XHCI controllers going to D3 - it's with the root ports they are 
connected to.  And the issue occurs with D3hot.

An earlier version of the series did do something like this where it was 
quirks for the PCI IDs for the root ports but it has two problems:

1) It covers too many things.  The same PCI ID is used for a second root 
port that is unaffected by the issue.  So this means the quirk needs to 
look at the topology to make sure the right device combination is quirked.

2) It doesn't scale.  I don't have any reason to believe the constraints 
requirements change which means we'll be adding new quirks with every 
single new CPU.

> 
> Note I'm not saying this is the best solution. I'm just trying to understand what you mean with " the PCIe root port that is used for XHCI tunneling" .
> 
> I also see that Rafael has said elsewhere in the thread that he needs to think a bit about how to best handle this ...
> 

I have done a prototype for your callback proposal, and I've got 
something working at least for amd-pmc.  It only calls the callback one 
time rather than at suspend.

Unless I get some feedback from Bjorn that the callback proposal is a 
bad idea I'll post something later today.