From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756324AbdKGS3x (ORCPT ); Tue, 7 Nov 2017 13:29:53 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:49692 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755764AbdKGS3v (ORCPT ); Tue, 7 Nov 2017 13:29:51 -0500 From: Nayna Jain Subject: Re: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance To: Alexander.Steffen@infineon.com, linux-integrity@vger.kernel.org Cc: zohar@linux.vnet.ibm.com, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, peterhuewe@gmx.de, jarkko.sakkinen@linux.intel.com, tpmdd@selhorst.net, jgunthorpe@obsidianresearch.com, patrickc@us.ibm.com References: <20171017203232.2262-1-nayna@linux.vnet.ibm.com> <20171017203232.2262-3-nayna@linux.vnet.ibm.com> <5ef60315f2254b3b8bcc217a572280e5@infineon.com> Date: Tue, 7 Nov 2017 23:59:10 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <5ef60315f2254b3b8bcc217a572280e5@infineon.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-TM-AS-GCONF: 00 x-cbid: 17110718-0008-0000-0000-000008D436BA X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008027; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000239; SDB=6.00942533; UDB=6.00475458; IPR=6.00722821; BA=6.00005676; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017899; XFM=3.00000015; UTC=2017-11-07 18:29:47 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17110718-0009-0000-0000-000044AB2100 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-07_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711070246 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/20/2017 08:12 PM, Alexander.Steffen@infineon.com wrote: >> The TPM burstcount status indicates the number of bytes that can >> be sent to the TPM without causing bus wait states. Effectively, >> it is the number of empty bytes in the command FIFO. >> >> This patch optimizes the tpm_tis_send_data() function by checking >> the burstcount only once. And if the burstcount is valid, it writes >> all the bytes at once, permitting wait state. >> >> After this change, performance on a TPM 1.2 with an 8 byte >> burstcount for 1000 extends improved from ~41sec to ~14sec. >> >> Suggested-by: Ken Goldman in >> conjunction with the TPM Device Driver work group. >> Signed-off-by: Nayna Jain >> Acked-by: Mimi Zohar >> --- >> drivers/char/tpm/tpm_tis_core.c | 42 +++++++++++++++---------------------- >> ---- >> 1 file changed, 15 insertions(+), 27 deletions(-) >> >> diff --git a/drivers/char/tpm/tpm_tis_core.c >> b/drivers/char/tpm/tpm_tis_core.c >> index b33126a35694..993328ae988c 100644 >> --- a/drivers/char/tpm/tpm_tis_core.c >> +++ b/drivers/char/tpm/tpm_tis_core.c >> @@ -316,7 +316,6 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> u8 *buf, size_t len) >> { >> struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); >> int rc, status, burstcnt; >> - size_t count = 0; >> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >> >> status = tpm_tis_status(chip); >> @@ -330,35 +329,24 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> u8 *buf, size_t len) >> } >> } >> >> - while (count < len - 1) { >> - burstcnt = get_burstcount(chip); >> - if (burstcnt < 0) { >> - dev_err(&chip->dev, "Unable to read burstcount\n"); >> - rc = burstcnt; >> - goto out_err; >> - } >> - burstcnt = min_t(int, burstcnt, len - count - 1); >> - rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv- >>> locality), >> - burstcnt, buf + count); >> - if (rc < 0) >> - goto out_err; >> - >> - count += burstcnt; >> - >> - if (wait_for_tpm_stat(chip, TPM_STS_VALID, chip- >>> timeout_c, >> - &priv->int_queue, false) < 0) { >> - rc = -ETIME; >> - goto out_err; >> - } >> - status = tpm_tis_status(chip); >> - if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >> - rc = -EIO; >> - goto out_err; >> - } >> + /* >> + * Get the initial burstcount to ensure TPM is ready to >> + * accept data. >> + */ >> + burstcnt = get_burstcount(chip); >> + if (burstcnt < 0) { >> + dev_err(&chip->dev, "Unable to read burstcount\n"); >> + rc = burstcnt; >> + goto out_err; >> } >> >> + rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv->locality), >> + len - 1, buf); >> + if (rc < 0) >> + goto out_err; >> + >> /* write last byte */ >> - rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality), >> buf[count]); >> + rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality), buf[len- >> 1]); >> if (rc < 0) >> goto out_err; >> >> -- >> 2.13.3 > This seems to fail reliably with my SPI TPM 2.0. I get EIO when trying to send large amounts of data, e.g. with TPM2_Hash, and subsequent tests seem to take an unusual amount of time. More analysis probably has to wait until November, since I am going to be in Prague next week. Thanks Alex for testing these.. Did you get the chance to do any further analysis ? Thanks & Regards,        - Nayna > Alexander > From mboxrd@z Thu Jan 1 00:00:00 1970 From: nayna@linux.vnet.ibm.com (Nayna Jain) Date: Tue, 7 Nov 2017 23:59:10 +0530 Subject: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance In-Reply-To: <5ef60315f2254b3b8bcc217a572280e5@infineon.com> References: <20171017203232.2262-1-nayna@linux.vnet.ibm.com> <20171017203232.2262-3-nayna@linux.vnet.ibm.com> <5ef60315f2254b3b8bcc217a572280e5@infineon.com> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On 10/20/2017 08:12 PM, Alexander.Steffen at infineon.com wrote: >> The TPM burstcount status indicates the number of bytes that can >> be sent to the TPM without causing bus wait states. Effectively, >> it is the number of empty bytes in the command FIFO. >> >> This patch optimizes the tpm_tis_send_data() function by checking >> the burstcount only once. And if the burstcount is valid, it writes >> all the bytes at once, permitting wait state. >> >> After this change, performance on a TPM 1.2 with an 8 byte >> burstcount for 1000 extends improved from ~41sec to ~14sec. >> >> Suggested-by: Ken Goldman in >> conjunction with the TPM Device Driver work group. >> Signed-off-by: Nayna Jain >> Acked-by: Mimi Zohar >> --- >> drivers/char/tpm/tpm_tis_core.c | 42 +++++++++++++++---------------------- >> ---- >> 1 file changed, 15 insertions(+), 27 deletions(-) >> >> diff --git a/drivers/char/tpm/tpm_tis_core.c >> b/drivers/char/tpm/tpm_tis_core.c >> index b33126a35694..993328ae988c 100644 >> --- a/drivers/char/tpm/tpm_tis_core.c >> +++ b/drivers/char/tpm/tpm_tis_core.c >> @@ -316,7 +316,6 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> u8 *buf, size_t len) >> { >> struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); >> int rc, status, burstcnt; >> - size_t count = 0; >> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >> >> status = tpm_tis_status(chip); >> @@ -330,35 +329,24 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> u8 *buf, size_t len) >> } >> } >> >> - while (count < len - 1) { >> - burstcnt = get_burstcount(chip); >> - if (burstcnt < 0) { >> - dev_err(&chip->dev, "Unable to read burstcount\n"); >> - rc = burstcnt; >> - goto out_err; >> - } >> - burstcnt = min_t(int, burstcnt, len - count - 1); >> - rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv- >>> locality), >> - burstcnt, buf + count); >> - if (rc < 0) >> - goto out_err; >> - >> - count += burstcnt; >> - >> - if (wait_for_tpm_stat(chip, TPM_STS_VALID, chip- >>> timeout_c, >> - &priv->int_queue, false) < 0) { >> - rc = -ETIME; >> - goto out_err; >> - } >> - status = tpm_tis_status(chip); >> - if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >> - rc = -EIO; >> - goto out_err; >> - } >> + /* >> + * Get the initial burstcount to ensure TPM is ready to >> + * accept data. >> + */ >> + burstcnt = get_burstcount(chip); >> + if (burstcnt < 0) { >> + dev_err(&chip->dev, "Unable to read burstcount\n"); >> + rc = burstcnt; >> + goto out_err; >> } >> >> + rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv->locality), >> + len - 1, buf); >> + if (rc < 0) >> + goto out_err; >> + >> /* write last byte */ >> - rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality), >> buf[count]); >> + rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality), buf[len- >> 1]); >> if (rc < 0) >> goto out_err; >> >> -- >> 2.13.3 > This seems to fail reliably with my SPI TPM 2.0. I get EIO when trying to send large amounts of data, e.g. with TPM2_Hash, and subsequent tests seem to take an unusual amount of time. More analysis probably has to wait until November, since I am going to be in Prague next week. Thanks Alex for testing these.. Did you get the chance to do any further analysis ? Thanks & Regards, ?????? - Nayna > Alexander > -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:57576 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755753AbdKGS3w (ORCPT ); Tue, 7 Nov 2017 13:29:52 -0500 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA7ITqF8054689 for ; Tue, 7 Nov 2017 13:29:52 -0500 Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by mx0a-001b2d01.pphosted.com with ESMTP id 2e3fyjem8t-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 07 Nov 2017 13:29:50 -0500 Received: from localhost by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 7 Nov 2017 11:29:49 -0700 From: Nayna Jain Subject: Re: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance To: Alexander.Steffen@infineon.com, linux-integrity@vger.kernel.org Cc: zohar@linux.vnet.ibm.com, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, peterhuewe@gmx.de, jarkko.sakkinen@linux.intel.com, tpmdd@selhorst.net, jgunthorpe@obsidianresearch.com, patrickc@us.ibm.com References: <20171017203232.2262-1-nayna@linux.vnet.ibm.com> <20171017203232.2262-3-nayna@linux.vnet.ibm.com> <5ef60315f2254b3b8bcc217a572280e5@infineon.com> Date: Tue, 7 Nov 2017 23:59:10 +0530 MIME-Version: 1.0 In-Reply-To: <5ef60315f2254b3b8bcc217a572280e5@infineon.com> Content-Type: text/plain; charset=windows-1252; format=flowed Message-Id: Sender: linux-integrity-owner@vger.kernel.org List-ID: On 10/20/2017 08:12 PM, Alexander.Steffen@infineon.com wrote: >> The TPM burstcount status indicates the number of bytes that can >> be sent to the TPM without causing bus wait states. Effectively, >> it is the number of empty bytes in the command FIFO. >> >> This patch optimizes the tpm_tis_send_data() function by checking >> the burstcount only once. And if the burstcount is valid, it writes >> all the bytes at once, permitting wait state. >> >> After this change, performance on a TPM 1.2 with an 8 byte >> burstcount for 1000 extends improved from ~41sec to ~14sec. >> >> Suggested-by: Ken Goldman in >> conjunction with the TPM Device Driver work group. >> Signed-off-by: Nayna Jain >> Acked-by: Mimi Zohar >> --- >> drivers/char/tpm/tpm_tis_core.c | 42 +++++++++++++++---------------------- >> ---- >> 1 file changed, 15 insertions(+), 27 deletions(-) >> >> diff --git a/drivers/char/tpm/tpm_tis_core.c >> b/drivers/char/tpm/tpm_tis_core.c >> index b33126a35694..993328ae988c 100644 >> --- a/drivers/char/tpm/tpm_tis_core.c >> +++ b/drivers/char/tpm/tpm_tis_core.c >> @@ -316,7 +316,6 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> u8 *buf, size_t len) >> { >> struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); >> int rc, status, burstcnt; >> - size_t count = 0; >> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >> >> status = tpm_tis_status(chip); >> @@ -330,35 +329,24 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> u8 *buf, size_t len) >> } >> } >> >> - while (count < len - 1) { >> - burstcnt = get_burstcount(chip); >> - if (burstcnt < 0) { >> - dev_err(&chip->dev, "Unable to read burstcount\n"); >> - rc = burstcnt; >> - goto out_err; >> - } >> - burstcnt = min_t(int, burstcnt, len - count - 1); >> - rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv- >>> locality), >> - burstcnt, buf + count); >> - if (rc < 0) >> - goto out_err; >> - >> - count += burstcnt; >> - >> - if (wait_for_tpm_stat(chip, TPM_STS_VALID, chip- >>> timeout_c, >> - &priv->int_queue, false) < 0) { >> - rc = -ETIME; >> - goto out_err; >> - } >> - status = tpm_tis_status(chip); >> - if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >> - rc = -EIO; >> - goto out_err; >> - } >> + /* >> + * Get the initial burstcount to ensure TPM is ready to >> + * accept data. >> + */ >> + burstcnt = get_burstcount(chip); >> + if (burstcnt < 0) { >> + dev_err(&chip->dev, "Unable to read burstcount\n"); >> + rc = burstcnt; >> + goto out_err; >> } >> >> + rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv->locality), >> + len - 1, buf); >> + if (rc < 0) >> + goto out_err; >> + >> /* write last byte */ >> - rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality), >> buf[count]); >> + rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality), buf[len- >> 1]); >> if (rc < 0) >> goto out_err; >> >> -- >> 2.13.3 > This seems to fail reliably with my SPI TPM 2.0. I get EIO when trying to send large amounts of data, e.g. with TPM2_Hash, and subsequent tests seem to take an unusual amount of time. More analysis probably has to wait until November, since I am going to be in Prague next week. Thanks Alex for testing these.. Did you get the chance to do any further analysis ? Thanks & Regards, - Nayna > Alexander >