Comment 26 for bug 1903864

I was giving the debugging of this some more time.
I was finding that some newer kernels don't expose /sys/class/tpm/tpm0/device/cancel
anymore which is the reason in some places for the "Could not guess TPM cancel path".
One can trick around these cases by providing a fake cancel path tou:
  $ touch /tmp/foo-cancel
  $ ... -tpmdev passthrough,id=tpm0,path=/dev/tpm0,cancel-path=/tmp/foo-cancel

With that the use case of TPm passthrough is working even with the kernel
not exposing thise e.g.:
  $ sudo qemu-system-x86_64 -nodefaults -S -display none -monitor stdio \
   -tpmdev passthrough,id=tpm0,path=/dev/tpm0,cancel-path=/tmp/foo-cancel \
   -device tpm-tis,tpmdev=tpm0
But it does so with 1:4.2-3ubuntu6.12 just as much as with 1:4.2-3ubuntu6.13.

But that isn't everything. I further realized that using the TPM as passthrough
will once the guest detaches set it in a disabled state. In that state it will
be rather useless until the next reboot of the host system to re-initialize it.
That further explains some of the inconsistent results.

Further we were so far relying on user-testing of our code e.g. in #14 / #15
thanks to Andre. But having him not available makes me need to verify it alone.
Since I lack his setup I need to use what I have and that alignes to what
the patch is meant to fix as described by upstream.

I was able to confirm that the formerly misleading error:
$ sudo qemu-system-x86_64 -tpmdev emulator,id=tpm0
qemu-system-x86_64: -tpmdev emulator,id=tpm0: tpm-emulator: Failed to send CMD_SET_DATAFD: Success
qemu-system-x86_64: -tpmdev emulator,id=tpm0: tpm-emulator: Could not cleanly shutdown the TPM: Success

Is now much more clear:
$ sudo qemu-system-x86_64 -tpmdev emulator,id=tpm0
qemu-system-x86_64: -tpmdev emulator,id=tpm0: tpm-emulator: parameter 'chardev' is missing

So I was able to confirm that this indeed fixes an issue.
If it fixes the originally reported issue - I can't say as I don't have
the same setup.

I was also setting up another laptop for this to test tpm passthrough there.
I was able to verify all I've said above and didn't find a regression (e.g.
with swtpm usage that worked before an after), but I also didn't re-create the
good results of #14/#15.
Also consdiering all the limitatons I've identified that even the intended
testcase as documented above works fine - but it does so with the old and
with the new version.

Let me I'd summarize:
a) we seem to not regress TPM usage (and the reported use case works)
   Although it would not need this fix for it :-)
b) we fix a real issue (although just a misleading message)
c) the SRU combines a few fixes, the other alone would qualify for an SRU
   so releasing this is not "a useless update for just this error message"

Therefore I'd want to set this verified to release the fix.
If later on Andre or jaromir come back and confirm that while helpful it
didn't fix "their" issue we can split that into a new bug and consider potential
steps and fixes for that in this new case.

IMHO that would allow to resolve this at no cost (effort of re-spinning,
re-reviewing, re-testing the SRU). And has no drawback I could identify.