On 5/18/2022 4:21 PM, James Bottomley wrote:
Actually, this is nothing to do with the TIMEOUTS_A-D: those are the
maximum times before a command should complete. This is the minimum
time we should wait between pokes of the TPM to see if it is ready.
Usually the use case is:
while (read device status gives not ready)
tpm_msleep(something)
The tpm_msleep gives up CPU control (to prevent huge amounts of busy
waiting) but before 424eaf910c32 ("tpm: reduce polling time to usecs
for even finer granularity") we would sleep for an entire tick (time
taken to make the process runnable) before the next poll, and since
most TPM commands don't return immediately, that was a gate on how fast
you could do simple TPM operations (like PCR extend).
As far as I know, no TCG spec gives any details of the minimum wait
time between poll cycles, so this is really something the manufacturer
has to tell us.
Just for completeness, my soak test did run to completion, but my TPM
has since failed and dropped off the bus, so simply reverting this
patch (5ef924d9e2e8) isn't sufficient to fully fix my problem.
[FYI] The TPM vendors explained that polling interrupts TPM command processing. This will make commands take longer. They recommend adaptive sleep time based on (at least) the command. E.g., getcapability, pcrread, ... are fast so a short sleep is appropriate. create, createprimary are slow so a longer sleep will have better performance.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
