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

[Daniel Henrique Barboza]

On 5/12/20 1:44 PM, Daniel P. Berrangé wrote:
> On Tue, May 12, 2020 at 01:21:40PM -0300, Daniel Henrique Barboza wrote:
>>
>>
>> On 5/12/20 12:53 PM, Daniel P. Berrangé wrote:
>>> On Tue, May 12, 2020 at 11:21:52AM -0400, Stefan Berger wrote:
>>>> On 5/11/20 7: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.
>>>>
>>>>
>>>> QEMU won't accept multiple TIS or CRB devices, though.
>>>
>>> The commit message says you can do 2 at a time:
>>>
>>>     "Although redundant, there is currently no technical
>>>      limitation for a guest to assign both a vTPM and a TPM Proxy at the
>>>      same time."
>>>
>>> is that text not accurate ?
>>
>>
>> It is. A TPM Proxy is not considered a TIS or CRB, so it's ok to mix it up
>> with another TPM device. The allowed combinations are:
>>
>> - single vTPM device
>> - single TPM Proxy device
>> - a single vTPM + single TPM Proxy devices
> 
> So we do need multiple  <tpm> support in the XML for this last case
> then.


Indeed we do. Working on it ATM. The plan is for this kind of XML format to be valid:


     <tpm model='tpm-tis'>
       <backend type='passthrough'>
         <device path='/dev/tpm0'/>
       </backend>
     </tpm>
     <tpm model='spapr-tpm-proxy'>
       <backend type='passthrough'>
         <device path='/dev/tpmrm0'/>
       </backend>
     </tpm>



A TPM Proxy allows a second TPM device to be added, as long as it's not a second TPM
Proxy device.


Thanks,

DHB

> 
> 
> Regards,
> Daniel
>