Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1713555
| From | Alexander Stein <alexander.stein@systec-electronic.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [tpmdd-devel] [PATCH v2] tpm_tis: fix stall after iowrite*()s |
| Date | 2017-08-17 08:00 +0200 |
| Message-ID | <ufm0x-tP-3@gated-at.bofh.it> (permalink) |
| References | <uaSNr-47E-9@gated-at.bofh.it> <ueQtI-5Vx-13@gated-at.bofh.it> <ufdTl-3MC-41@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wednesday 16 August 2017 17:15:55, Ken Goldman wrote: > On 8/15/2017 4:13 PM, Haris Okanovic wrote: > > ioread8() operations to TPM MMIO addresses can stall the cpu when > > immediately following a sequence of iowrite*()'s to the same region. > > > > For example, cyclitest measures ~400us latency spikes when a non-RT > > usermode application communicates with an SPI-based TPM chip (Intel Atom > > E3940 system, PREEMPT_RT_FULL kernel). The spikes are caused by a > > stalling ioread8() operation following a sequence of 30+ iowrite8()s to > > the same address. I believe this happens because the write sequence is > > buffered (in cpu or somewhere along the bus), and gets flushed on the > > first LOAD instruction (ioread*()) that follows. > > > > The enclosed change appears to fix this issue: read the TPM chip's > > access register (status code) after every iowrite*() operation to > > amortize the cost of flushing data to chip across multiple instructions. > > I worry a bit about "appears to fix". It seems odd that the TPM device > driver would be the first code to uncover this. Can anyone confirm that > the chipset does indeed have this bug? No, there was already a similar problem in e1000e where a PCIe read stalled the CPU, hence no interrupts are serviced. See https://www.spinics.net/lists/linux-rt-users/msg14077.html AFAIK there was no outcome though. > I'd also like an indication of the performance penalty. We're doing a > lot of work to improve the performance and I worry that "do a read after > every write" will have a performance impact. Realtime will always affect performance, but IMHO the latter is much more important. Best regards, Alexander
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v2] tpm_tis: fix stall after iowrite*()s Haris Okanovic <haris.okanovic@ni.com> - 2017-08-15 22:20 +0200
Re: [tpmdd-devel] [PATCH v2] tpm_tis: fix stall after iowrite*()s Ken Goldman <kgold@linux.vnet.ibm.com> - 2017-08-16 23:20 +0200
Re: [tpmdd-devel] [PATCH v2] tpm_tis: fix stall after iowrite*()s Alexander Stein <alexander.stein@systec-electronic.com> - 2017-08-17 08:00 +0200
Re: [tpmdd-devel] [PATCH v2] tpm_tis: fix stall after iowrite*()s Sebastian Andrzej Siewior <sebastian.siewior@linutronix.de> - 2017-08-17 12:40 +0200
Re: [tpmdd-devel] [PATCH v2] tpm_tis: fix stall after iowrite*()s Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-08-17 19:20 +0200
Re: [tpmdd-devel] [PATCH v2] tpm_tis: fix stall after iowrite*()s Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-08-19 19:10 +0200
csiph-web