On Sun, Feb 24, 2019 at 02:12:03PM -0800, David Tolnay wrote: > We avoid implementing TIS or any other TPM-specific interface mechanism, > and we avoid implementing ACPI or OF or PNP or I2C or any other > additional bus necessitated by the existing set of Linux TPM drivers > which we wouldn't otherwise need. > > The virtio driver performs discovery via virtio, which crosvm implements > already for all of its supported devices. This substantially reduces the > amount of TPM-specific code compared to your suggestions, and lowers the > barrier to entry for implementing TPM support in other hypervisors which > I hope we agree is beneficial. I don't necessarily because it adds to our codebase. > Turning this around a different way, suppose that there already was a > virtio TPM driver in the kernel. For me as a hypervisor implementer, > what advantages do you see that would make me decide to implement > TPM-specific virtual hardware emulation in the form of TIS rather than > simply leveraging a virtio driver like for other virtual devices? Well the way QEMU does it is already proven model. We don't need anything new to kernel. You can take the ideas from there how to implement the user space. > QEMU dedicated to TIS. Without a virtio driver (or socsim, or something > else that avoids TPM-specific hardware emulation for device discovery), > QEMU and crosvm and other hypervisors need to reproduce a TIS > implementation. Conceptually this is simple but it is still a quite > substantial barrier compared to not needing any TPM-specific discovery. If we are speaking about user space code, 1000+ lines is nothing. Adding more complexity to the kernel is much more expensive . /Jarkko
