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 *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. > >> 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. Bjorn
