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

[Stefan Berger <stefanb@linux.vnet.ibm.com>]

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. 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