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