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. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
