[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c60a0d22-5002-49a4-8dc9-a7b689ed685f@amd.com>
Date: Mon, 29 Jul 2024 09:56:18 -0500
From: Wei Huang <wei.huang2@....com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, netdev@...r.kernel.org,
Jonathan.Cameron@...wei.com, corbet@....net, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
alex.williamson@...hat.com, gospo@...adcom.com, michael.chan@...adcom.com,
ajit.khaparde@...adcom.com, somnath.kotur@...adcom.com,
andrew.gospodarek@...adcom.com, manoj.panicker2@....com,
Eric.VanTassell@....com, vadim.fedorenko@...ux.dev, horms@...nel.org,
bagasdotme@...il.com, bhelgaas@...gle.com
Subject: Re: [PATCH V3 03/10] PCI/TPH: Add pci=notph to prevent use of TPH
On 7/25/24 16:29, Bjorn Helgaas wrote:
> On Wed, Jul 24, 2024 at 03:05:59PM -0500, Wei Huang wrote:
>>
>>
>> On 7/23/24 17:41, Bjorn Helgaas wrote:
>>> On Wed, Jul 17, 2024 at 03:55:04PM -0500, Wei Huang wrote:
>>>> TLP headers with incorrect steering tags (e.g. caused by buggy driver)
>>>> can potentially cause issues when the system hardware consumes the tags.
>>>
>>> Hmm. What kind of issues? Crash? Data corruption? Poor
>>> performance?
>>
>> Not crash or functionality errors. Usually it is QoS related because of
>> resource competition. AMD has
>
> Looks like you had more to say here?
I hit the send button too fast. What I wanted to say was there will be
AMD QoS patches to control TPH. Note that they will be hooked up under
x86/resctrl. Since they are AMD specific, it will be independent from
PCIe subsystem code.
>
> I *assume* that both the PH hint and the Steering Tags are only
> *hints* and there's no excuse for hardware to corrupt anything (e.g.,
> by omitting cache maintenance) even if the hint turns out to be wrong.
> If that's the case, I assume "can potentially cause issues" really
> just means "might lead to lower performance". That's what I want to
> clarify and confirm.
Corrrect, only QoS-related concerns. There won't be any correctness
concerns.
>
>>>> Provide a kernel option, with related helper functions, to completely
>>>> prevent TPH from being enabled.
>>>
>>> Also would be nice to have a hint about the difference between "notph"
>>> and "nostmode". Maybe that goes in the "nostmode" patch? I'm not
>>> super clear on all the differences here.
>>
>> I can combine them. Here is the combination and it meaning based on TPH
>> Control Register values:
>>
>> Requestor Enable | ST Mode | Meaning
>> ---------------------------------------------------------------
>> 00 | xx | TPH disabled (i.e. notph)
>> 01 | 00 | TPH enabled, NO ST Mode (i.e. nostmode)
>> 01 or 11 | 01 | Interrupt Vector mode
>> 01 or 11 | 10 | Device specific mode
>>
>> If you have any other thoughts on how to approach these modes, please
>> let me know.
>
> IIRC, there's no interface in this series that reall does anything
> with TPH per se; drivers would only use the ST-related things.
>
> If that's the case, maybe "pci=notph" isn't needed yet.
I can go with it. There will be a BIOS option to turn it off on AMD
platform. I would expect similar options on other vendors' platforms. So
I am not overly concerned about dropping pci=notph.
>
> Bjorn
Powered by blists - more mailing lists