From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLxuC-0001U8-4y for qemu-devel@nongnu.org; Wed, 20 Jan 2016 13:54:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLxu7-0007eq-AF for qemu-devel@nongnu.org; Wed, 20 Jan 2016 13:54:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLxu7-0007ed-2W for qemu-devel@nongnu.org; Wed, 20 Jan 2016 13:54:51 -0500 Date: Wed, 20 Jan 2016 20:54:47 +0200 From: "Michael S. Tsirkin" Message-ID: <20160120185328-mutt-send-email-mst@redhat.com> References: <1451921002-8263-1-git-send-email-stefanb@us.ibm.com> <1451921002-8263-2-git-send-email-stefanb@us.ibm.com> <20160120171258-mutt-send-email-mst@redhat.com> <201601201536.u0KFanwG004844@d01av04.pok.ibm.com> <20160120155802.GA32541@redhat.com> <201601201607.u0KG7NtZ004518@d03av03.boulder.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201601201607.u0KG7NtZ004518@d03av03.boulder.ibm.com> Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: Stefan Berger , qemu-devel@nongnu.org, jb613w@att.com, quan.xu@intel.com, silviu.vlasceanu@gmail.com, hagen.lauer@huawei.com On Wed, Jan 20, 2016 at 11:06:45AM -0500, Stefan Berger wrote: > "Michael S. Tsirkin" wrote on 01/20/2016 10:58:02 AM: > > > From: "Michael S. Tsirkin" > > > > > On Wed, Jan 20, 2016 at 10:36:41AM -0500, Stefan Berger wrote: > > > "Michael S. Tsirkin" wrote on 01/20/2016 10:20:58 AM: > > > > > > > From: "Michael S. Tsirkin" > > > > > > > > > > > > > The CUSE TPM and associated tools can be found here: > > > > > > > > > > https://github.com/stefanberger/swtpm > > > > > > > > > > (please use the latest version) > > > > > > > > > > To use the external CUSE TPM, the CUSE TPM should be started as > follows: > > > > > > > > > > # terminate previously started CUSE TPM > > > > > /usr/bin/swtpm_ioctl -s /dev/vtpm-test > > > > > > > > > > # start CUSE TPM > > > > > /usr/bin/swtpm_cuse -n vtpm-test > > > > > > > > > > QEMU can then be started using the following parameters: > > > > > > > > > > qemu-system-x86_64 \ > > > > > [...] \ > > > > > -tpmdev cuse-tpm,id=tpm0,cancel-path=/dev/null,path=/ > > dev/vtpm-test > > > \ > > > > > -device tpm-tis,id=tpm0,tpmdev=tpm0 \ > > > > > [...] > > > > > > > > > > > > > > > Signed-off-by: Stefan Berger > > > > > Cc: Eric Blake > > > > > > > > Before we add a dependency on this interface, > > > > I'd rather see this interface supported in kernel > > > > and not just in CUSE. > > > > > > For using the single hardware TPM, we have the passthrough type. > > It's usage is > > > limited. > > > > > > CUSE extends the TPM character device interface with ioctl's. Behind the > > > character device we can implement a TPM 1.2 and a TPM 2. Both TPM > > > implementations require large amounts of code, which I don't thinkshould go > > > into the Linux kernel itself. So I don't know who would implement this > > > interface inside the Linux kernel. > > > > > > Stefan > > > > > > > BTW I'm not talking about the code - I'm talking about the interfaces here. > > > > One way would be to add support for these interface support in the kernel. > > > > Maybe others can be replaced with QMP events so management > > can take the necessary action. > > > > As long as this is not the case, I suspect this code will have to stay > > out of tree :( We can't depend on interfaces provided solely by cuse > > devices on github. > > Why is that? I know that the existing ioctls cannot be modified anymore once > QEMU accepts the code. So I don't understand it. Some of the ioctls are only > useful when emulating a hardware device, Maybe they can be replaced with QMP events? These could be emitted unconditionally, and ignored by management in passthrough case. > so there's no need for them in a > kernel interface unless one was to put the vTPM code into the Linux kernel, but > I don't see that this is happening. What is better about a kernel interface > versus one implemented by a project on github assuming that the existing ioctls > are stable? What is the real reason here? > > Stefan > That someone went to the trouble of reviewing the interface for long-term maintainability, portability etc. That it obeys some existing standards for API use, coding style etc and will continue to. In other words, kernel is already a dependency for QEMU. > > > > > > > > -- > > MST > > >