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 Tue, May 12, 2020 at 01:51:33PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> 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>

Right, that sounds ok.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




[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