On 01/11/2018 09:02 AM, Laszlo Ersek wrote:
On 01/11/18 13:40, Igor Mammedov wrote:
On Wed, 10 Jan 2018 17:45:52 +0100
Laszlo Ersek <[email protected]> wrote:
(My understanding is that the guest has to populate the CRB, and then
kick the hypervisor, so at least the register used for kicking must be
in MMIO (or IO) space. And firmware cannot allocate MMIO or IO space
(for platform devices). Thus, the register block must reside at a
QEMU-determined GPA. Once we do that, why bother about RAM allocation?)
MMIO doesn't have to be fixed nor exist at all, we could use
linker write to file operation in FW for switching from guest
to QEMU. That's obviously intrusive work for FW and QEMU
compared to hardcodded address in both QEMU and FW but as
benefit changes to QEMU and FW don't have to be tightly coupled
and layout could be changed whenever need arises.
Marc-André wrote, "The [CRB] region is registered at the same address as
TIS (it's not entirely clear from the spec it is supposed to be there,
but my laptop tpm use the same)."
And, the spec declares the register block at the fixed range
FED4_0000h-FED4_4FFFh.
How about this:
(1) stick with the TPM specs and implement the TIS and/or CRB interfaces,
(2) *except* make the base address of the register block a compat
property for the QEMU device,
(3) generate data tables (TPM2) and AML tables (SSDT/_DSM) that expose
the device to the guest OS as ACPI or ACPI+CRB (i.e., "fTPM"), *not* TIS
and/or CRB
Why? Linux doesn't use this type of interface. Actually, for the TIS the
base address has been hard coded as well.
(4) in the generated ACPI payload, adhere to the compat property (i.e.,
generate the base address values from the compat prop),
(5) expose the base address stand-alone in a new fw_cfg file as well.
Benefits as I see it:
- register block can move around from one QEMU release to next,
Why would we need that? fed4_0000 is presumably reserved for TPM device
interfaces and shouldn't clash with anything in the future. With the PPI
memory at ffff_0000 - ffff_00ffI am not so sure. Here we could use the
proposed QEMU ACPI table and a hard-coded address, ffff_0000 at the
beginning. Would that not solve it? Why not?
- migration remains functional (ACPI comes from source host, but it
matches the device model on the target host, due to the compat prop),
- firmware remains dumb about TPM activations (OS calls ACPI calls
virtual hardware),
Linux doesn't use the ACPI interface from what I can tell.
What are 'TPM activations'? We have a TIS interface for example that
SeaBIOS uses to initialize the TPM1.2 / TPM2.
- the ACPI-to-hardware interface is dictated by an industry spec, so we
Do you have a pointer to this spec?
don't have to invent and document a paravirtual interface. If it ever
becomes necessary for the firmware to directly access the TPM
hardware (for example, to replay physical presence commands queued by
the OS), fw can rely on the same industry spec, only the base address
has to be updated -- which is available stand-alone from the named
fw_cfg file.
Thanks
Laszlo
_______________________________________________
SeaBIOS mailing list
[email protected]
https://mail.coreboot.org/mailman/listinfo/seabios
