On Tue, Feb 21, 2012 at 05:30:32PM -0500, Stefan Berger wrote:
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?
Absolutely.
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 ?
It's ugly I hope you can do something saner:
ops->send_command(....)
with command encapsulating the relevant info.
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?