Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752061AbdIMTBp convert rfc822-to-8bit (ORCPT ); Wed, 13 Sep 2017 15:01:45 -0400 Received: from mout.gmx.net ([212.227.17.20]:51469 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751810AbdIMTBk (ORCPT ); Wed, 13 Sep 2017 15:01:40 -0400 Date: Wed, 13 Sep 2017 12:01:20 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <3c418974-a4c7-518e-b218-f6373c10209e@linux.vnet.ibm.com> References: <20170906125643.5070-1-nayna@linux.vnet.ibm.com> <20170906125643.5070-2-nayna@linux.vnet.ibm.com> <20170906161246.GA9747@obsidianresearch.com> <3c418974-a4c7-518e-b218-f6373c10209e@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [tpmdd-devel] [PATCH v2 1/4] tpm: ignore burstcount to improve tpm_tis send() performance. To: tpmdd-devel@lists.sourceforge.net, Ken Goldman CC: linux-ima-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org From: Peter Huewe Message-ID: <5C86BF5C-76AA-47DB-B15B-DE524823CF9F@gmx.de> X-Provags-ID: V03:K0:JxVaxGb6TGu48cDUOcJZAREJdiefBZtyP3TFA7I0iYfJhntIaCF 5yxL7P3Y1aVNqw/u+QBDT+M8QK/lncu+3lAdL1tlGTe7JY6yKBwuyRU4kE4u0Z79sClSKtt H/XaEUSY1jM/a040k+S9kesnBeXyAygjObeC1ZK7+T0dvR4z+fysTyKW5ReDFDsDl5yZQVx eA1k6LG1FjOn7zn+lc0wg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Hft0kL0SJm0=:gTqNCSLY1SNKz1X/AYidzO DJwAebN1/l4QuKD4LCP6PFGP4mGt3OWvBWxCmQjUUTlnn8luKfK1Nb96Lm9XXNWBDgazIi9pS anf/GWuXgEUXb78mhlO2NNOrVcQRr8u4cdwzmseyC4UpjFOC3Yn1M5TQhkdCmdmkghmHWVHAZ pJ7qkrGqEqC1jexJSurjkVF/xjUiixk+fdunqf/BTcnUk9IciYgtccqKNmpRB3EoOrxpThPNV 44mJRhzXb+ASrYQjUtpu1fx1s/6Ez6SFKHCQumf++b/SJHytq+LjqGYVCRYFAAD2UZLjOkT/i QYvq5pMLJMs6cY8HHflcOfyWvVQlFEiJpvuv6BN0OhCcYloiAfV7H7FKAswrxYzg8VTXQG76H vo0UbKonekmkVz0evfMpulCclTmVID1Q6Z+Svf3lJ1fYF1U0eC9TG15YglAU4LwG44TRgpRhL JqBq6+BVaE73BJFgBqHf6baTusYfl8WZao1POdVylPKjMeGQcnk89WlLAQ2zFR4zO6QBFbps2 nq5cLTKdmrtlcy7a7YCJs2mhZjZR4moNf5moGd5SGSIAr+mLJbLR6LTIfvoJOCcY0q7+Gp42X MN2PJAbyGOkQDX9lW7XXwZyY5JV0XLOjBoVsG9R01NDjHtrgcn9kI1jNfcuJ+d7x06KjqdLcQ d8b0gyjykToDGuzIpYeHmXwG2e5LcmBaQK1Suq+m8PdnbIdEh5m1xwyqLVZPkKFmFtlbsk3D8 rBOoGIbewapYVfl8qekozLWOjOVGy3fKliB94KtfUw5bmUnaNAnTb1JQ4ArXc9wZy5pk1xRAZ PmtYaoDWiSddrIjNNJ4hOAnH4cqQfjRvqsyyzeVxlNCkt7BK/E= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1277 Lines: 42 Am 13. September 2017 11:52:12 GMT-07:00 schrieb Ken Goldman : >On 9/6/2017 12:12 PM, Jason Gunthorpe wrote: >> >> The problem with this approach is that the TPM could totally block >> the CPU for very long periods of time. >> >> It seems very risky to enable.. >> > >How would you characterize "very long"? > >The TPM vendors confirm that they empty the FIFO at internal speeds >that >are comparable to the bus speed. Thus, any stall will be sub-usec. Is >that an issue? If the tpm does behave correctly, this is fine. If the tpm hangs for whatever reason, your machine is frozen and you will never figure out why. That's my concern there. However ddwg seems fine. > >In addition, new TPMs have ever larger FIFO's, making stalls less >likely >going forward. But also reduced the polling loops that introduce the performance penalty ;) > > >------------------------------------------------------------------------------ >Check out the vibrant tech community on one of the world's most >engaging tech sites, Slashdot.org! http://sdm.link/slashdot >_______________________________________________ >tpmdd-devel mailing list >tpmdd-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/tpmdd-devel -- Sent from my mobile