From: Stefan Berger <stefanb@linux.vnet.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org, andreas.niederl@iaik.tugraz.at
Subject: Re: [Qemu-devel] [PATCH V14 2/7] Add TPM (frontend) hardware interface (TPM TIS) to Qemu
Date: Tue, 21 Feb 2012 17:30:32 -0500 [thread overview]
Message-ID: <4F441B08.6000306@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120221195812.GB9062@redhat.com>
On 02/21/2012 02:58 PM, Michael S. Tsirkin wrote:
> On Tue, Feb 21, 2012 at 10:05:26AM -0500, Stefan Berger wrote:
>> On 02/21/2012 07:18 AM, Michael S. Tsirkin wrote:
>>>
>> When the backend delivers the response it checks whether the
>> interface is used in interrupt mode and raises the interrupt.
> IMO it's the frontend that should send interrupts.
> Yes it kind of works for isa anyway, but e.g. pci
> needs to update configuration etc.
>
The code that causes the interrupt to be raised is in the frontend. The
function doing that is invoked via callback from the backend. This
should be ok?
>> The
>> backend enters the frontend code with a callback. In this function
>> also a signal is sent that may wake up the main thread that, upon
>> suspend, may be waiting for the last command to be processed and be
>> sleeping on a condition variable.
>>
>> I now added a function to the backend interface that is invoked by
>> the frontend to notify the backend of a TPM request. The backend
>> code can then either notify a thread (passthrough and libtpms
>> driver) or create a response right away and invoke that callback to
>> the front-end to deliver the response (null driver). How frontend
>> and backend handle notifications is isolated to the frontend and
>> backend with some backends (libtpms, passthough) sharing the code
>> for how the notification is done.
>>
>> Stefan
> Right. And all the locking/threading can then be internal to the backend.
>
Do you really want to replace code like this in the frontend:
qemu_mutex_lock(&s->state_lock)
[...]
qemu_mutex_unlock(&s->state_lock)
with
s->be_driver->ops->state_lock(s->be_driver)
[...]
s->be_driver->ops->state_unlock(s->be_driver))
where the backend starts protecting frontend data structures ?
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
next prev parent reply other threads:[~2012-02-21 22:30 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-14 13:43 [Qemu-devel] [PATCH V14 0/7] Qemu Trusted Platform Module (TPM) integration Stefan Berger
2011-12-14 13:43 ` [Qemu-devel] [PATCH V14 1/7] Support for TPM command line options Stefan Berger
2011-12-14 13:43 ` [Qemu-devel] [PATCH V14 2/7] Add TPM (frontend) hardware interface (TPM TIS) to Qemu Stefan Berger
2012-02-20 8:51 ` Michael S. Tsirkin
2012-02-20 15:48 ` Stefan Berger
2012-02-20 19:37 ` Michael S. Tsirkin
2012-02-20 19:58 ` Stefan Berger
2012-02-23 20:47 ` Stefan Berger
2012-02-20 22:02 ` Michael S. Tsirkin
2012-02-21 0:43 ` Stefan Berger
2012-02-21 3:18 ` Michael S. Tsirkin
2012-02-21 11:19 ` Stefan Berger
2012-02-21 12:18 ` Michael S. Tsirkin
2012-02-21 15:05 ` Stefan Berger
2012-02-21 19:58 ` Michael S. Tsirkin
2012-02-21 22:30 ` Stefan Berger [this message]
2012-02-21 23:08 ` Michael S. Tsirkin
2012-02-22 0:21 ` Stefan Berger
2012-02-22 4:34 ` Michael S. Tsirkin
2012-02-22 15:03 ` Stefan Berger
2012-02-22 17:55 ` Stefan Berger
2012-03-02 12:02 ` Stefan Berger
2012-03-04 22:59 ` Michael S. Tsirkin
2012-03-05 15:44 ` Stefan Berger
2012-03-05 15:46 ` Stefan Berger
2011-12-14 13:43 ` [Qemu-devel] [PATCH V14 3/7] Add a debug register Stefan Berger
2011-12-14 13:43 ` [Qemu-devel] [PATCH V14 4/7] Build the TPM frontend code Stefan Berger
2011-12-14 13:43 ` [Qemu-devel] [PATCH V14 5/7] Add a TPM Passthrough backend driver implementation Stefan Berger
2012-02-20 19:51 ` Michael S. Tsirkin
2012-02-20 20:25 ` Stefan Berger
2012-02-20 21:15 ` Michael S. Tsirkin
2012-02-21 1:03 ` Stefan Berger
2012-03-21 23:27 ` Anthony Liguori
2012-02-20 20:01 ` Michael S. Tsirkin
2012-02-20 21:12 ` Stefan Berger
2012-02-20 21:30 ` Michael S. Tsirkin
2012-02-21 0:30 ` Stefan Berger
2011-12-14 13:43 ` [Qemu-devel] [PATCH V14 6/7] Introduce --enable-tpm-passthrough configure option Stefan Berger
2011-12-14 13:43 ` [Qemu-devel] [PATCH V14 7/7] Add fd parameter for TPM passthrough driver Stefan Berger
2012-01-12 16:59 ` [Qemu-devel] [PATCH V14 0/7] Qemu Trusted Platform Module (TPM) integration Paul Moore
2012-01-16 19:21 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F441B08.6000306@linux.vnet.ibm.com \
--to=stefanb@linux.vnet.ibm.com \
--cc=andreas.niederl@iaik.tugraz.at \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).