Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752408AbdHPVPR (ORCPT ); Wed, 16 Aug 2017 17:15:17 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:34920 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752130AbdHPVPP (ORCPT ); Wed, 16 Aug 2017 17:15:15 -0400 Subject: Re: [tpmdd-devel] [PATCH v2] tpm_tis: fix stall after iowrite*()s To: linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org Cc: tpmdd-devel@lists.sourceforge.net References: <20170804215651.29247-1-haris.okanovic@ni.com> <20170815201308.20024-1-haris.okanovic@ni.com> From: Ken Goldman Date: Wed, 16 Aug 2017 17:15:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170815201308.20024-1-haris.okanovic@ni.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17081621-0048-0000-0000-000001D4A174 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007557; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000221; SDB=6.00903308; UDB=6.00452497; IPR=6.00683524; BA=6.00005537; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016726; XFM=3.00000015; UTC=2017-08-16 21:15:12 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17081621-0049-0000-0000-00004241ABD1 Message-Id: <13741b28-1b5c-de55-3945-e05911e5a4e2@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-16_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708160348 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1263 Lines: 23 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? 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.