From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGUh7-0003Oq-Qj for qemu-devel@nongnu.org; Fri, 15 Mar 2013 09:29:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UGUh6-0000rT-D6 for qemu-devel@nongnu.org; Fri, 15 Mar 2013 09:29:13 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:54781) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGUh6-0000rP-7F for qemu-devel@nongnu.org; Fri, 15 Mar 2013 09:29:12 -0400 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 15 Mar 2013 09:29:11 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 697D638C801A for ; Fri, 15 Mar 2013 09:29:07 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2FDT6Dp23658632 for ; Fri, 15 Mar 2013 09:29:07 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2FDT5TF021677 for ; Fri, 15 Mar 2013 10:29:05 -0300 Message-ID: <51432221.3050609@linux.vnet.ibm.com> Date: Fri, 15 Mar 2013 09:29:05 -0400 From: Stefan Berger MIME-Version: 1.0 References: <1361987275-26289-1-git-send-email-stefanb@linux.vnet.ibm.com> <1361987275-26289-2-git-send-email-stefanb@linux.vnet.ibm.com> <87obel867v.fsf@blackfin.pond.sub.org> In-Reply-To: <87obel867v.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V27 1/7] Support for TPM command line options List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Luiz Capitulino , qemu-devel@nongnu.org, anthony@codemonkey.ws, mst@redhat.com On 03/15/2013 03:36 AM, Markus Armbruster wrote: > I missed this one, because it wasn't cc'ed to QMP maintainers, the > subject mentions only command line, not QMP, and even the body talks > only about the human monitor command, not QMP. Noticed it only when > git-pull touched qapi-schema.json. Please try harder to help Luiz and > me keep track of QMP changes. I apologize for that. > > I gave the QMP interface and its documentation a look-over now. It's > just a look-over, because passthrough requires a box with TPM enabled, > which I don't have handy, so I can't test anything. > > A few comments inline. > > Stefan Berger writes: > + > +@item -tpmdev @var{backend} ,id=@var{id} [,@var{options}] > +@findex -tpmdev > +Backend type must be: > + > +The specific backend type will determine the applicable options. > +The @code{-tpmdev} option requires a @code{-device} option. > You mean -tpmdev creates just a backend, so for a usable device you also > need to create a frontend with -device? Yes, just like any other device. { + .name = "query-tpm", + .args_type = "", + .mhandler.cmd_new = qmp_marshal_input_query_tpm, + }, + + { + .name = "query-tpm-models", + .args_type = "", + .mhandler.cmd_new = qmp_marshal_input_query_tpm_models, + }, + + { + .name = "query-tpm-types", + .args_type = "", + .mhandler.cmd_new = qmp_marshal_input_query_tpm_types, + }, + + { .name = "chardev-add", .args_type = "id:s,backend:q", .mhandler.cmd_new = qmp_marshal_input_chardev_add, > You imitated the bad examples that lack documentation instead the good > ones that have it. Please fix that in a followup patch. Will do by sending it to the list and cc'ing you. +{ + if (qemu_opts_foreach(qemu_find_opts("tpmdev"), + tpm_init_tpmdev, NULL, 1) != 0) { + return -1; + } + + atexit(tpm_cleanup); > Routine atexit() question: what happens when the program terminates > abnormally? atext() callbacks don't run then. Impact of not doing > cleanup on the system? In case the TPM is currently not operating on a command there will be no impact. In case the TPM is operating on a command, it will hold the thread inside /dev/tpm0 until the command has finished. The solution here is to write a byte into sysfs file to terminate the TPM from further executing the command and return; this code exists and is being invoked in all other cases than abnormal termination obviously. What other choices do we have? Do we need a signal handler that runs on SIGSEGV and provide a registration function for those functions that need to run on abnormal termination? Stefan