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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 5/11/20 8:50 AM, Daniel Henrique Barboza wrote:


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:
[...]
[...]

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.

Update: I tried it out the new "backend" approach and didn't enjoy the results.
It ended up replicating a large amount of existing cgroup/dac/selinux code that
handles the existing "passthrough" backend and, all said and done, it didn't alleviate
that much the parsing/format XML logic comparing to the alternative.

I chose then to go to the simpler route - adding a new 'passthrough' model called
'spapr-tpm-proxy'. This will not scale well if/when more TPM proxies devices are
added in the future, but we can cross that bridge when we come to it.


DHB





Thanks,

DHB



Regards,
Daniel





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux