Re: [Qemu-devel] [PATCH V14 2/7] Add TPM (frontend) hardware interface (TPM TIS) to Qemu

["Michael S. Tsirkin" <mst@redhat.com>]

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