On 01/16/2018 05:35 PM, Kevin O'Connor wrote:
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,
QEMU does implement the ACPI code. The firmware may implement a subset
of what the specs are describing. The array of flags helps to decouple
the ACPI code and the firmware and allows OVMF and SeaBIOS and possibly
others to only implement a subset of the functionality.
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)?
Its SeaBIOS vor OVMF reporting to ACPI what it implements. QEMU doesn't
know what the firmware implements.
Stefan
-Kevin
_______________________________________________
SeaBIOS mailing list
[email protected]
https://mail.coreboot.org/mailman/listinfo/seabios
