From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37140)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanb@linux.vnet.ibm.com>) id 1bDZ9H-0000Bb-6J
	for qemu-devel@nongnu.org; Thu, 16 Jun 2016 11:24:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanb@linux.vnet.ibm.com>) id 1bDZ9D-0002qa-8d
	for qemu-devel@nongnu.org; Thu, 16 Jun 2016 11:24:02 -0400
Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:37546
	helo=mx0a-001b2d01.pphosted.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanb@linux.vnet.ibm.com>) id 1bDZ9D-0002qP-2n
	for qemu-devel@nongnu.org; Thu, 16 Jun 2016 11:23:59 -0400
Received: from pps.filterd (m0098413.ppops.net [127.0.0.1])
	by mx0b-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id
	u5GFJ69c033119
	for <qemu-devel@nongnu.org>; Thu, 16 Jun 2016 11:23:58 -0400
Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154])
	by mx0b-001b2d01.pphosted.com with ESMTP id 23jswcqq3q-1
	(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)
	for <qemu-devel@nongnu.org>; Thu, 16 Jun 2016 11:23:58 -0400
Received: from localhost
	by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <qemu-devel@nongnu.org> from <stefanb@linux.vnet.ibm.com>;
	Thu, 16 Jun 2016 09:23:57 -0600
References: <20160120154657.GF13215@redhat.com>
	<569FADC7.7060301@linux.vnet.ibm.com>
	<20160120162220.GH13215@redhat.com> <20160121113632.GC2446@work-vm>
	<57FA3A002D66E049AA7792D931B894C7060F5494@MOKSCY3MSGUSRGB.ITServices.sbc.com>
	<945CA011AD5F084CBEA3E851C0AB28894B8C3A14@SHSMSX101.ccr.corp.intel.com>
	<575E92DB.3080904@linux.vnet.ibm.com> <20160615193019.GB7300@work-vm>
	<5761C092.5070702@linux.vnet.ibm.com> <20160616080520.GA2249@work-vm>
	<20160616082517.GC11426@redhat.com>
From: Stefan Berger <stefanb@linux.vnet.ibm.com>
Date: Thu, 16 Jun 2016 11:20:27 -0400
MIME-Version: 1.0
In-Reply-To: <20160616082517.GC11426@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-Id: <5762C3BB.30201@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Daniel P. Berrange" <berrange@redhat.com>, "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Stefan Berger <stefanb@us.ibm.com>, "mst@redhat.com" <mst@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "hagen.lauer@huawei.com" <hagen.lauer@huawei.com>, "Xu, Quan" <quan.xu@intel.com>, "silviu.vlasceanu@gmail.com" <silviu.vlasceanu@gmail.com>, "SERBAN, CRISTINA" <cs1731@att.com>, "SHIH, CHING C" <cs1815@att.com>

On 06/16/2016 04:25 AM, Daniel P. Berrange wrote:
> On Thu, Jun 16, 2016 at 09:05:20AM +0100, Dr. David Alan Gilbert wrote:
>> * Stefan Berger (stefanb@linux.vnet.ibm.com) wrote:
>>> On 06/15/2016 03:30 PM, Dr. David Alan Gilbert wrote:
>> <snip>
>>
>>>> So what was the multi-instance vTPM proxy driver patch set about?
>>> That's for containers.
>> Why have the two mechanisms? Can you explain how the multi-instance
>> proxy works; my brief reading when I saw your patch series seemed
>> to suggest it could be used instead of CUSE for the non-container case.
> One of the key things that was/is not appealing about this CUSE approach
> is that it basically invents a new ioctl() mechanism for talking to
> a TPM chardev. With in-kernel vTPM support, QEMU probably doesn't need
> to have any changes at all - its existing driver for talking to TPM
> char devices ought to just work. All that would be required is libvirt
> support too configure the vTPM instances.

The issue here is mainly the control channel as stated in the other email.

The CUSE TPM allows users to provide the name of the device that will 
appear in /dev. Since the kernel TPM driver basically owns the 
/dev/tpm%d names, a CUSE TPM should use a different name. I don't quite 
understand why such a device should not be able to offer an ioctl 
interface for its control channel? In case of the CUSE TPM it's not a 
hardware device underneath but a software emulation of a hardware device 
that needs an additional control channel to allow certain functionality 
to be reached that is typically hidden by the device driver. It just 
happens to have a compatible data channel that works just like /dev/tpm%d.

The ioctl interface is in my opinion only a problem in so far as the 
control channel commands can be larger than what the Linux CUSE driver 
supports so that the implementation had to work around this restriction. 
As stated in the other email, there's the possibility of using the TPM 
emulator with socket interfaces where the data and control channels can 
now use any combination of UnixIO and TCP sockets, so two UnixIO sockets 
(for data and control) are possible.

     Stefan