On Fri, Feb 22, 2019 at 05:07:19PM -0500, Michael S. Tsirkin wrote: > 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. What kind of specialized hardware this requires? /Jarkko
