On 2025-12-12 17:38, Andrew Cooper wrote:
On 12/12/2025 10:29 pm, Jason Andryuk wrote:
Pass the TPM2 ACPI table so that the device can be found by a PVH dom0.
Otherwise dom0 shows:
tpm_tis MSFT0101:00: [Firmware Bug]: failed to get TPM2 ACPI table
tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -22
TCPA is "Trusted Computing Platform Alliance table", but it is really
the table for a TPM 1.2. Use that as the comment as it's more
identifiable for readers.
While doing this, move ACPI_SIG_WPBT to alpabetize the entries.
It's probably worth stating that this brings PVH dom0 more in line with
PV dom0.
"This exposes TPM event log tables on PVH dom0, bring it in line with a
PV dom0."
Signed-off-by: Jason Andryuk <[email protected]>
Acked-by: Andrew Cooper <[email protected]>
Thanks!
---
Only TPM2 has been tested.
AIUI, a TPM 1.2 is probed without the ACPI entry, so it is usable.
But since I know the table exists, I added it.
Yeah - I'd have asked you to do this if you hadn't already.
That said, it highlights that the Trenchboot series needs to grow the
ability to hide the TPM from dom0, both the APCI tables and blind probing.
I presume that tboot already does this, because I'm sure it's been
tested, right...?
Tested which way? This has *not* been tested with tboot, but I think
it's orthogonal.
After tboot launches Xen, tboot is dormant until Xen calls back into
tboot for shutdown. Control of the TPM passes to Xen/Dom0. This is
expected with DRTM and TPMs. The TPM locality differentiates TPM
accesses inside and outside the measured launch environment.
The TPM ACPI table specifies the location of the TPM Event Log - a
reserved RAM region. There are other ACPI PNP devices to specify the
TPM device itself. Those are in DSDT or SSDT (I think), so distinct
from the event log table - the subject of this patch.
Regards,
Jason
