[SeaBIOS] Saving a few bytes across a reboot
stefanb at linux.vnet.ibm.com
Thu Jan 11 15:29:14 CET 2018
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 <lersek at redhat.com> 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
> 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.
More information about the SeaBIOS