From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S03ud-0006DZ-3W for qemu-devel@nongnu.org; Tue, 21 Feb 2012 23:34:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S03ub-0005aW-Mp for qemu-devel@nongnu.org; Tue, 21 Feb 2012 23:34:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S03ub-0005aI-Ex for qemu-devel@nongnu.org; Tue, 21 Feb 2012 23:34:41 -0500 Date: Wed, 22 Feb 2012 06:34:29 +0200 From: "Michael S. Tsirkin" Message-ID: <20120222043427.GA26903@redhat.com> References: <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> <4F443508.8070408@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F443508.8070408@linux.vnet.ibm.com> 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: Stefan Berger Cc: qemu-devel@nongnu.org, Andreas Niederl On Tue, Feb 21, 2012 at 07:21:28PM -0500, Stefan Berger wrote: > 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. Naturally. But it could be an implementation detail of the backend. > 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 In that case, you can take the qemu lock in your backend and avoid locking in the frontend completely. -- MST