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

[Daniel Henrique Barboza]

On 5/11/20 8:28 AM, Daniel P. Berrangé wrote:
> On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza wrote:
>>
>>
>> On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
>>> On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
>> [...]
>>>> 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
>>
>> I think adding a new backend type is sensible. Re-using the passthrough type
>> and making the differentiation with 'model', for a device that doesn't
>> operate exactly as a regular vTPM but can coexist with other vTPM devices,
>> will make for a lot of IFs in the code.
> 
> Currently libvirt only allows a single <tpm>, but we can trivially
> lift that restriction to allow multiple if desired too.

I don't believe it'll be necessary. Since it's only this TPM Proxy device that
can coexist with other TPMs, my idea is to do what I did here in this series,
but instead of creating a new device type I'll re-use the existing TPM device
in a 'tpmproxy' pointer in the domain for this case.

I'll still thinking about whether a new backend type is warranted or not. For
this PPC64 case alone it'll be simpler to just add a new 'model' called
'spapr-tpm'-proxy' for the existing TPM passthrough type. Creating a new
backend type makes it easier to add other TPM Proxy devices when other archs
implement it though.



Thanks,

DHB


> 
> Regards,
> Daniel
>