On Fri, Feb 22, 2019 at 11:59:23PM +0200, Jarkko Sakkinen
wrote:> On Fri, Feb 22, 2019 at 02:31:37PM -0700, Jason Gunthorpe wrote:
> > On Fri, Feb 22, 2019 at 04:16:01PM -0500, Michael S. Tsirkin wrote:
> > > On Fri, Feb 22, 2019 at 07:30:16AM -0800, James Bottomley wrote:
> > > > On Thu, 2019-02-21 at 18:14 -0800, David Tolnay wrote:
> > > > > Add a config TCG_VIRTIO_VTPM which enables a driver
providing the
> > > > > guest kernel side of TPM over virtio.
> > > >
> > > > What's the use case for using this over the current
non-virtio vTPM?.
> > > > I always thought virtio was about guest to host transport
efficiency,
> > > > but the phsical TPM, being connected over a very slow bus,
is about as
> > > > inefficient as you can get in that regard, so why do we need
to use
> > > > virtio to drive the virtual one?
> > >
> > > I can't say for sure about TPM.
> > >
> > > But generally there are many reasons to do virtio rather than
emulating
> > > a hardware device.
> >
> > We already have a xen 'virtioish' TPM driver, so I don't
think there
> > is a good reason to block a virtio driver if someone cares about
> > it. There are enough good reasons to prefer virtio to other options,
> > IMHO.
> >
> > Provided it meets the general requirements for new virtio stuff you
> > outlined.
>
> Yeah, absolutely we can consider this.
>
> For me it boils down to testing and documentation part.
>
> No plans to merge code that I'm unable to run...
>
> /Jarkko
I do this sometimes. One can't require samples for all supported
hardware. If I can check that code matches spec, I might settle for
that.
--
MST
