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

[Marc-André Lureau]

On Wed, Mar 1, 2017 at 10:56 PM Daniel P. Berrange <address@hidden>
wrote:

> On Wed, Mar 01, 2017 at 06:32:19PM +0000, Marc-André Lureau wrote:
> > Hi
> >
> > On Wed, Mar 1, 2017 at 10:20 PM Michael S. Tsirkin <address@hidden>
> wrote:
> >
> > >
> > > > You're also tieing the code
> > > > into the QEMU release cycle, again for no tangible benefit.
> > >
> > > No need for ABI stability would be the benefit.
> > >
> >
> > We are talking about the control channel ABI (the data channel is using
> TCG
> > defined command streams afaict - don't remember what it is called)
> >
> >
> > >
> > > > Conceptually
> > > > swtpm does not depend on, or require, QEMU to be useful - it can have
> > > > other non-QEMU consumers - bundling with QEMU is not helpful there.
> > >
> > > Maybe it could but it isn't.
> > >
> >
> > Right, it would be reasonable to have qemu provide it's own private
> "swtpm"
> > (linking with libtpms, doing most of the job), that way it wouldn't have
> to
> > rely on a stable ABI (as long as the process isn't shared across
> different
> > qemu versions, which should be quite easy to achieve)
>
> I think we need to expect to have a stable ABI no matter what. During
> upgrade cycles, it is desirable to be able to upgrade the swtpm process
> assocatied with a running VM. Whether this is done by restarting the
> process & having QEMU reconnect, or by re-exec'ing swtpm and keeping the
> FD open, you still end up with newer swtpm talking to an older QEMU. Or
>

I am not sure why this is required. You could require that both qemu &
helper process are restarted in this case so they stay in sync, no?


> conversely you might have setup swtpm processes to populate a number of
> CUSE devices, and then later launch QEMU binaries to connect to them - at
>

I would rather avoid CUSE device with this private qemu helper process.


> which point there's no guarantee the QEMU version hasn't been upgraded -
> or the user could have requested a custom QEMU binary to virt-install,
> etc.
>

The point is to have the qemu binary tight with the helper process. If they
are incompatible, you broke your installation, it should fail to start.

-- 
Marc-André Lureau