On Mon, Feb 20, 2012 at 07:43:05PM -0500, Stefan Berger wrote:
> 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
Well, this is just an idea, please do not take this as
a request or anything like that. Maybe it is a dumb one.
Maybe something like what you describe.
Alternatively, I imagined that you can pass a copy
or pointer of the necessary state to the backend,
which queues the command and wakes the worker.
In the reverse direction, backend queues a response
and when OS polls you dequeue it and update state.
Can this work?
--
MST
