On Tue, Feb 13, 2018 at 03:29:20PM -0500, Stefan Berger wrote:
[...]
In these 0x400 bytes we have 256 bytes that are used for configuration flags
describing the supported opcode as you previously described. This array
allows us to decouple the firmware implementation from the ACPI code and we
need not hard code what is supported in the firmware inside the ACPI code
(which would be difficult to do anyway since in QEMU we would not what
firmware will be started and what PPI opcodes are support) and the ppi sysfs
entries in Linux for example show exactly those PPI opcodes that are
supported. The firmware needs to set those flags and the firmware knows what
it supports.
I hope we can settle that this device is the right path.
It seems that the primary purpose of the 0x400 virtual device is to
pass information from firmware to QEMU (specifically to pass the list
of supported PPI opcodes to the QEMU generated AML code). Passing
information between firmware and QEMU is not new territory, and fw_cfg
was specifically built to do this. I'd prefer to use fw_cfg if we
need to pass information between firmware and QEMU.
That said, I don't see why this list is needed - why not just
implement the same opcodes in both UEFI and SeaBIOS and be done with
it? The spec defines 22 actions, and most of these are permutations
of 4 basic features (Enable, Activate, Clear, SetOwnerInstall).
[...]
I initially had PPI SeaBIOS code write into the TPM TIS device's memory into
some custom addresses. I'd consider this a hack.
Well, sure, it could be considered a hack. But, it seems to me the
whole PPI spec is a bit of a hack. If elegance isn't an option,
settle for simplicity?
-Kevin