[PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device

[Daniel P. Berrangé]

On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
> On Fri, May 08, 2020 at 04:30:09PM -0400, Stefan Berger wrote:
> > On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
> > > QEMU 4.1.0 introduced a new device type called TPM Proxy, currently
> > > implemented by PPC64 guests via a new virtual device called
> > > 'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info).
> > > 
> > > The TPM Proxy device interacts with a TPM Resource Manager, a host
> > > device capable of multiplexing the host TPM with multiple processes.
> > > This allows multiple guests to access some TPM features at the
> > > same time. Note that this mode of operation does not provide
> > > full TPM features to be available for the guest - for that case
> > > the guest still needs to assign a vTPM device (tpm-spapr for
> > > PPC64 guests). Although redundant, there is currently no technical
> > > limitation for a guest to assign both a vTPM and a TPM Proxy at the
> > > same time.
> > > 
> > > This patch adds documentation and schema for the new TPM Proxy device.
> > > An example of a TPM Proxy device connected to a TPM Resource Manager
> > > '/dev/tpmrm0' will look like this:
> > > 
> > >    <tpmproxy model='spapr-tpm-proxy'>
> > >      <device path='/dev/tpmrm0'/>
> > >    </tpmproxy>
> > 
> > We already have:
> > 
> >     <backend type='passthrough'>
> >       <device path='/dev/tpm0'/>
> >     </backend>
> > 
> > Now what is the difference between this tpm-proxy device using /dev/tpmrm0
> > and having the existing passthrough device use /dev/tpmrm0?  Is there any
> > useful filtering going on by the tpm-proxy device? If not, why not use
> > passthrough with /dev/tpmrm0?
> 
> It's a different guest side interface, the H_TPM_COMM hypercall
> instead of the other PAPR TPM interface.  To which "why?" is a very
> good question, but it's there now, so there's not much we can do about
> it.

That's ok. Even though its a different guest interface, it is still
conceptually a TPM device at a high level, so we should be reusing
the existing <tpm> device type. At most we should add a new backend
type


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|