On Tue, Jan 16, 2018 at 05:01:51PM -0500, Stefan Berger wrote:
On 01/16/2018 01:36 PM, Kevin O'Connor wrote:
On Tue, Jan 16, 2018 at 11:41:02AM -0500, Stefan Berger wrote:
- tp = (struct tpm_ppi *)(u32)qemu->tpmppi_address;
- dprintf(DEBUG_tcg, "TCGBIOS: TPM PPI struct at %p\n", tp);
- memset(&tp->func, 0, sizeof(tp->func));
- switch (qemu->tpmppi_version) {
- case TPM_PPI_VERSION_1_30:
switch (qemu->tpm_version) {case TPM_VERSION_1_2:memcpy(&tp->func, tpm12_ppi_funcs, sizeof(tpm12_ppi_funcs));break;case TPM_VERSION_2:memcpy(&tp->func, tpm2_ppi_funcs, sizeof(tpm2_ppi_funcs));break;}Can you elaborate on what this does? Why is SeaBIOS filling a memory addreses created by QEMU? Why wouldn't QEMU just fill it with what it wants directly?
QEMU merely creates the device and the ACPI code. SeaBIOS implements which codes the user can send. The above array inside the virtual device contains flags that describe the codes that the user can send. If OVMF was to implement less codes, less bytes would be set. If another firmware implemented the possibility to prevent the user from sending certain codes, the TPM_PPI_FUNC_BLOCKED flag could be set for example so that ACPI would refuse to set the code for the next reboot. It's parametrizing the interface between ACPI and firmware.
Is this the right approach? If QEMU has all the code to emulate the TPM hardware and QEMU has all the code to build the ACPI tables describing that hardware - why doesn't it just implement the PPI functions itself on a reboot? I'll defer to Laszlo, Igor, Michael, etc, but this seems like a complex firmware<->qemu interface and I'm not sure I understand the gain.
The above aside, if there's a need to communicate firmware capabilities to QEMU (so that QEMU can build the ACPI tables describing that capability), can we reuse the writable fw_cfg file system to transfer that information (instead of having the firmware fill an area of memory)?
-Kevin