From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rzzxu-0005hx-TQ for qemu-devel@nongnu.org; Tue, 21 Feb 2012 19:21:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rzzxr-0001gH-0f for qemu-devel@nongnu.org; Tue, 21 Feb 2012 19:21:50 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]:47957) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rzzxq-0001fD-RU for qemu-devel@nongnu.org; Tue, 21 Feb 2012 19:21:46 -0500 Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 21 Feb 2012 17:21:41 -0700 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 28AC23E4004A for ; Tue, 21 Feb 2012 17:21:38 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1M0LbBo144160 for ; Tue, 21 Feb 2012 17:21:37 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1M0LXF1020545 for ; Tue, 21 Feb 2012 17:21:36 -0700 Message-ID: <4F443508.8070408@linux.vnet.ibm.com> Date: Tue, 21 Feb 2012 19:21:28 -0500 From: Stefan Berger MIME-Version: 1.0 References: <1323870202-25742-1-git-send-email-stefanb@linux.vnet.ibm.com> <1323870202-25742-3-git-send-email-stefanb@linux.vnet.ibm.com> <20120220220201.GD19278@redhat.com> <4F42E899.3010907@linux.vnet.ibm.com> <20120221031854.GA2502@redhat.com> <4F437DBE.90901@linux.vnet.ibm.com> <20120221121810.GA6975@redhat.com> <4F43B2B6.1040109@linux.vnet.ibm.com> <20120221195812.GB9062@redhat.com> <4F441B08.6000306@linux.vnet.ibm.com> <20120221230845.GD9062@redhat.com> In-Reply-To: <20120221230845.GD9062@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V14 2/7] Add TPM (frontend) hardware interface (TPM TIS) to Qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, Andreas Niederl On 02/21/2012 06:08 PM, Michael S. Tsirkin wrote: > On Tue, Feb 21, 2012 at 05:30:32PM -0500, Stefan Berger wrote: > > >> At the moment there are two backends that need threading: the >> libtpms and passthrough backends. Both will require locking of >> datastructures that belong to the frontend. Only the null driver >> doesn't need a thread and the main thread can call into the backend, >> create the response and call via callback into the frontend to >> deliver the repsonse. If structures are protected via mutxes then >> only the NULL driver (which we don't want anyway) may end up >> grabbing mutexes that really aren't necessary while the two other >> backends need them. I don't see the mitextes as problematic. The >> frontend at least protects its data structures for the callbacks and >> other API calls it offers and they simply are thread-safe. >> >> Stefan > Worst case, you can take a qemu mutex. Is tpm very > performance-sensitive to make contention on that > lock a problem? > We have to lock a common data structure 'somehow'. I don't see a way around it. The locking times are short since no major computations are done while the lock is held. Considering that the TPM TIS interface is a non-DMA, byte-by-byte send/receive interface, the performance problems, if at all a problem, are to be found somewhere else : VMExits for example; if interface is used in polling mode, then the interval between polls. Stefan