Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM

From: Stefan Berger <stefanb@linux.vnet.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>
Cc: "Stefan Berger" <stefanb@us.ibm.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"SERBAN, CRISTINA" <cs1731@att.com>,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>,
	"Xu, Quan" <quan.xu@intel.com>,
	"silviu.vlasceanu@gmail.com" <silviu.vlasceanu@gmail.com>,
	"hagen.lauer@huawei.com" <hagen.lauer@huawei.com>,
	"SHIH, CHING C" <cs1815@att.com>
Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM
Date: Wed, 1 Mar 2017 12:12:34 -0500	[thread overview]
Message-ID: <1d155a66-8806-8792-b82d-4bebabcd4971@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170301185414-mutt-send-email-mst@kernel.org>

On 03/01/2017 12:02 PM, Michael S. Tsirkin wrote:
> On Wed, Mar 01, 2017 at 04:31:04PM +0000, Daniel P. Berrange wrote:
>> On Wed, Mar 01, 2017 at 06:22:45PM +0200, Michael S. Tsirkin wrote:
>>> On Wed, Mar 01, 2017 at 09:50:38AM -0500, Stefan Berger wrote:
>>>> I had already proposed a linked-in version before I went to the out-of-process
>>>> design. Anthony's concerns back then were related to the code not being trusted
>>>> and a segfault in the code could bring down all of QEMU. That we have test
>>>> suites running over it didn't work as an argument. Some of the test suite are
>>>> private, though.
>>> Given how bad the alternative is maybe we should go back to that one.
>>> Same argument can be made for any device and we aren't making
>>> them out of process right now.
>>>
>>> IIMO it's less the in-process question (modularization
>>> of QEMU has been on the agenda since years and I don't
>>> think anyone is against it) it's more a code control/community question.
>> I rather disagree. Modularization of QEMU has seen few results
>> because it is generally a hard problem to solve when you have a
>> complex pre-existing codebase.  I don't think code control has
>> been a factor in this - as long as QEMU can clearly define its
>> ABI/API between core & the modular pieces, it doesn't matter
>> who owns the module. We've seen this with vhost-user which is
>> essentially outsourcing network device backend impls to a 3rd
>> party project.
> And it was done precisely for community reasons.  dpdk/VPP community is
> quite large and fell funded but they just can't all grok QEMU.  They
> work for hardware vendors and do baremetal things.  With the split we
> can focus on virtualization and they can focus on moving packets around.
>
>
>> QEMU's defined the vhost-user ABI/API and delegated
>> impl to something else.
> The vhost ABI isn't easy to maintain at all though. So I would not
> commit to that lightly without a good reason.
>
> It will be way more painful if the ABI is dictated by a 3rd party
> library.

Who should define it?