From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzrHt-0000cU-J3 for qemu-devel@nongnu.org; Tue, 21 Feb 2012 10:06:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzrHn-0002MU-8Y for qemu-devel@nongnu.org; Tue, 21 Feb 2012 10:05:53 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]:37131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzrHn-0002MO-11 for qemu-devel@nongnu.org; Tue, 21 Feb 2012 10:05:47 -0500 Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 21 Feb 2012 08:05:45 -0700 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id EA7F219D8026 for ; Tue, 21 Feb 2012 08:05:36 -0700 (MST) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1LF5cn2108984 for ; Tue, 21 Feb 2012 08:05:38 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1LF5a84028006 for ; Tue, 21 Feb 2012 08:05:37 -0700 Message-ID: <4F43B2B6.1040109@linux.vnet.ibm.com> Date: Tue, 21 Feb 2012 10:05:26 -0500 From: Stefan Berger MIME-Version: 1.0 References: <1323870202-25742-1-git-send-email-stefanb@linux.vnet.ibm.com> <1323870202-25742-3-git-send-email-stefanb@linux.vnet.ibm.com> <20120220220201.GD19278@redhat.com> <4F42E899.3010907@linux.vnet.ibm.com> <20120221031854.GA2502@redhat.com> <4F437DBE.90901@linux.vnet.ibm.com> <20120221121810.GA6975@redhat.com> In-Reply-To: <20120221121810.GA6975@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V14 2/7] Add TPM (frontend) hardware interface (TPM TIS) to Qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, andreas.niederl@iaik.tugraz.at On 02/21/2012 07:18 AM, Michael S. Tsirkin wrote: > On Tue, Feb 21, 2012 at 06:19:26AM -0500, Stefan Berger wrote: >> On 02/20/2012 10:18 PM, Michael S. Tsirkin wrote: >>> 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: >>> 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. >>> >> The OS doesn't necessarily need to poll. It is just one mode of >> operation of the OS, the other being interrupt-driven where the >> backend raises the interrupt once it has delivered the response to >> the frontend. >> >> >> Stefan > So you will also need to signal the frontend when it > must interrupt the guest. This is not a problem, > for example you can use a qemu_eventfd object for this. > When the backend delivers the response it checks whether the interface is used in interrupt mode and raises the interrupt. 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