On Sat Nov 11 17, Jason Gunthorpe wrote:
On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote:
Before the release_locality code would only actually release the
locality if the request use bit was set. So after it grabbed the
locality during probe it probably never released it. The idea with the
new code was to release it when it was no longer needed so another
requester would be able to take the tpm without having to wait for it
to be released.
If I recall, this was so that system level things outside linux could
access the TPM properly??
Yes, that is what drove this initially. I believe Jarkko was also
thinking of the possibility in the future where something like a vm
could request a locality as well, but that is just a hazy recollection
of emails from back then.
With the old code I think it would have to wait either
until the next time release_locality was called, or attempt to seize
the tpm with the seize bit in the access register. I need to read
through the spec some more, but does the tpm ever force a change when
the request use bit is set, or does it leave it up to the software
to deal with it and only gets involved in the case where the seize
bit has been set?
Do we handle these cases? Maybe something like that has happened..
Jason
If that is what happened in this case we should see the beenSeized bit
set in the access register (assuming the chip is doing things properly),
but it only had the tpmRegValidSts and tpmEstablishment bits set.
There is code in the interrupt handling that notices if the locality
changes if the chip has that capability, but I don't think there is
anything that deals with the seize bit. Another thing to be looked
at.
