Jarkko Sakkinen @ 2020-10-12 18:17 MST: > On Thu, Oct 01, 2020 at 11:09:20AM -0700, James Bottomley wrote: >> The current state of the TIS TPM is that interrupts have been globally >> disabled by various changes. The problems we got reported the last >> time they were enabled was interrupt storms. With my own TIS TPM, >> I've found that this is caused because my TPM doesn't do legacy >> cycles, The TIS spec (chapter 6.1 "Locality Usage Per Register") >> requires any TIS TPM without legacy cycles not to act on any write to >> an interrupt register unless the locality is enabled. This means if >> an interrupt fires after we relinquish the locality, the TPM_EOI in >> the interrupt routine is ineffective meaning the same interrupt >> triggers over and over again. This problem also means we can have >> trouble setting up interrupts on TIS TPMs because the current init >> code does the setup before the locality is claimed for the first time. >> >> James > > You should consider expanding the audience. Jerry, once you have some > bandwidth (no rush, does not land before rc2), it would be great that if > you could try this. I'm emphasizing this just because of the > intersection. I think it would also make senset to get tested-by from > Nayna. I will run some tests on some other systems I have access to. As noted in the other email I did a quick test with a t490s with an older bios that exhibits the problem originally reported when Stefan's patch enabled interrupts. > > Speaking of the changelog, I almost never have encounter a patch set > that does not have a changelog in the cover letter. And I'm not able to > interpret the process text in a way that it would ask to scatter > changelogs to the patches, and not put them to the cover letter [*]. > > Thus, I trust what I see as commodity. Not only that but it also helps a > lot with to see quickly what has changed, especially if the patches are > such that you have to take them in eventually. > > In my own patch sets, I've recently started to xref associated lore korg > discussions in the change log entries, when it applies. I started to do > this with the SGX series when I had missed to address a number of Boris' > comments. It has helped a lot with my own tracking and I assume it is > also helpful for reviewers and maintainers to get the context, when they > need it. > > The last paragraph is not something I demand. I'm merely just mentioning > it because I think it is a good practice for any patch set. > > [*] https://lore.kernel.org/linux-integrity/14edea1f5092c2b8442165756b2ee32e56bed1eb.camel@xxxxxxxxxxxxxxxxxxxxx/ > > /Jarkko
