From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rzddp-0003Xo-Rn for qemu-devel@nongnu.org; Mon, 20 Feb 2012 19:31:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rzddo-0006Rj-TA for qemu-devel@nongnu.org; Mon, 20 Feb 2012 19:31:37 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.146]:56629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rzddo-0006Re-QG for qemu-devel@nongnu.org; Mon, 20 Feb 2012 19:31:36 -0500 Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 20 Feb 2012 19:31:35 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id A90336E804A for ; Mon, 20 Feb 2012 19:30:48 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1L0UZN1039546 for ; Mon, 20 Feb 2012 19:30:41 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1L0UZX6026970 for ; Mon, 20 Feb 2012 19:30:35 -0500 Message-ID: <4F42E5AB.6030904@linux.vnet.ibm.com> Date: Mon, 20 Feb 2012 19:30:35 -0500 From: Stefan Berger MIME-Version: 1.0 References: <1323870202-25742-1-git-send-email-stefanb@linux.vnet.ibm.com> <1323870202-25742-6-git-send-email-stefanb@linux.vnet.ibm.com> <20120220213040.GC19278@redhat.com> In-Reply-To: <20120220213040.GC19278@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V14 5/7] Add a TPM Passthrough backend driver implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, andreas.niederl@iaik.tugraz.at On 02/20/2012 04:30 PM, Michael S. Tsirkin wrote: > On Wed, Dec 14, 2011 at 08:43:20AM -0500, Stefan Berger wrote: >> + >> +static void *tpm_passthrough_thread(void *d) >> +{ >> + TPMPassthruThreadParams *thr_parms = d; >> + TPMPassthruState *tpm_pt = thr_parms->tb->s.tpm_pt; >> + uint32_t in_len; >> + >> + dprintf("tpm_passthrough: THREAD IS STARTING\n"); >> + >> + /* start command processing */ >> + while (!tpm_pt->thread_terminate) { > IMO you want to checvk thread_terminate undet a lock/ > The way the termination flag is used along with the condition it isn't necessary to call it with a lock held. It may run into the condition but then be woken up with a signal and then again check the flag and terminate. >> + /* receive and handle commands */ >> + in_len = 0; >> + do { >> + dprintf("tpm_passthrough: waiting for commands...\n"); >> + >> + if (tpm_pt->thread_terminate) { >> + break; >> + } >> + > This will have to be duplicate in each backend, no? There is this sequence of code around the condition that helps us waiting for the front-end to send a command that is indeed repeated in every backend. I isolated that now but would like to keep the general thread more flexible and inside the individual backends. There is quite some code that is different in every backend. > So I would say make this logic part of backend > and expose some api. Ok, a single function for now: void tpm_backend_wait_for_command(TPMState *tpm_state); > You can then call it from backend or invoke > backend callbacks from frontend. > I was only going to invoke it from within the backend thread. Stefan