On 2/24/19 8:30 AM, James Bottomley wrote: > QEMU implements a virtual hardware emulation for discovery, but once > discovered all the packet communication is handed off to the vTPM > socket. > > The virtual hardware emulation can be anything we have a driver for. > TIS is the simplest, which is why I think they used it. TIS is > actually a simple interface specification, it supports discovery over > anything, but the discovery implemented in standard guest drivers is > over ACPI, OF and PNP. If you want more esoteric discovery methods, we > also support i2c. However, that latter is really only for embedded. I > think QEMU chose TIS because it works seamlessly on both Linux and > Windows guests. > > >> All of this is what I would like to avoid by using a virtio driver. > > How? Discovery is the part that you have to do, whether it's using > emulated physical mechanisms or virtual bus discovery. What I mean is that we avoid the need for *TPM-specific virtual hardware emulation* for discovery by using a virtio driver. 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. 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? > If you want to make this more concrete: I once wrote a pure socsim > packet TPM driver: > > https://patchwork.ozlabs.org/patch/712465/ > > Since you just point it at the network socket, it does no discovery at > all and works in any Linux environment that has net. I actually still > use it because a socsim TPM is easier to debug from the outside. > However it was 230 lines. Your device is 460 so that means about half > your driver is actually about discovery. It looks like all the comments in the virtio driver account for the difference, not necessarily discovery. But to put this in perspective, what we save is the 1000+ lines I see in 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. > The only reasons I can see to use a virtual bus is either because its > way more efficient (the storage/network use case) or because you've > stripped down the hypervisor so far that it's incapable of emulating > any physical device (the firecracker use case). Crosvm does fall under the Firecracker use case, I believe.
