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

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.

Regards, Daniel