qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM
Date: Wed, 1 Mar 2017 17:36:14 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

On Wed, Mar 01, 2017 at 12:12:34PM -0500, Stefan Berger wrote:
> 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?

I'm unsure of the best answer here right now. If swtpm is targetted as
being a generic component for use by arbitrary consumers, that'd tend
towards suggesting swtpm should "own" protocol definition. On the other
hand if we desire for QEMU to be able to replace swtpm with an alternate
impl, that might suggest QEMU define the protocol. Possibly it just does
not matter if there's an owner, as long as both swtpm & QEMU maintainers
colloborate & agree on the details.

>From a purely self-ish QEMU maintainer POV, I'd tend to suggest a QAPI
based protocol since we have two impls of that already (monitor and
guest agent) & thus its well understood by QEMU maintainers. Writing
a custom binary protocol might sound easy, but things can get complex
pretty quickly

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]