[SeaBIOS] Saving a few bytes across a reboot

[Stefan Berger]

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
> 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
>