From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzdpL-0005M7-5q for qemu-devel@nongnu.org; Mon, 20 Feb 2012 19:43:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzdpJ-0008Kl-Sa for qemu-devel@nongnu.org; Mon, 20 Feb 2012 19:43:31 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]:36275) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzdpJ-0008KV-Q3 for qemu-devel@nongnu.org; Mon, 20 Feb 2012 19:43:29 -0500 Received: from /spool/local by e1.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 20 Feb 2012 19:43:27 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id B56ED6E8049 for ; Mon, 20 Feb 2012 19:43:05 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1L0h6l9207498 for ; Mon, 20 Feb 2012 19:43:06 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1L0h5XZ032172 for ; Mon, 20 Feb 2012 19:43:05 -0500 Message-ID: <4F42E899.3010907@linux.vnet.ibm.com> Date: Mon, 20 Feb 2012 19:43:05 -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> In-Reply-To: <20120220220201.GD19278@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@iaik.tugraz.at On 02/20/2012 05:02 PM, Michael S. Tsirkin wrote: > On Wed, Dec 14, 2011 at 08:43:17AM -0500, Stefan Berger wrote: >> +/* >> + * Send a TPM request. >> + * Call this with the state_lock held so we can sync with the receive >> + * callback. >> + */ >> +static void tpm_tis_tpm_send(TPMState *s, uint8_t locty) >> +{ >> + TPMTISState *tis =&s->s.tis; >> + >> + tpm_tis_show_buffer(&tis->loc[locty].w_buffer, "tpm_tis: To TPM"); >> + >> + s->command_locty = locty; >> + s->cmd_locty =&tis->loc[locty]; >> + >> + /* w_offset serves as length indicator for length of data; >> + it's reset when the response comes back */ >> + tis->loc[locty].status = TPM_TIS_STATUS_EXECUTION; >> + tis->loc[locty].sts&= ~TPM_TIS_STS_EXPECT; >> + >> + s->to_tpm_execute = true; >> + qemu_cond_signal(&s->to_tpm_cond); >> +} > What happens IIUC is that frondend sets to_tpm_execute > and signals a condition, and backend clears it > and waits on a condition. > > So how about moving all the signalling > and locking out to backend, and have frontend > invoke a callback to signal it? > > The whole threading thing then becomes a work-around > for a backend that does not support select, > instead of spilling out into frontend? > How do I get the lock calls (qemu_mutex_lock(&s->state_lock)) out of the frontend? Do you want me to add callbacks to the backend interface for locking (s->be_driver->ops->state_lock(s)) and one for unlocking (s->be_driver->ops->state_unlock(tpm_be)) of the state that really belongs to the front-end (state is 's') and invoke it as shown in parenthesis and still keep s->state_lock around? Ideally the locks would end up being 'nop's' if select() was available, but in the end all backend will need to support that lock. [The lock protects the common structure so that the thread in the backend can deliver the response to a request while the OS for example polls the hardware interface for its current state.] Stefan