[SeaBIOS] Saving a few bytes across a reboot

Stefan Berger stefanb at linux.vnet.ibm.com
Thu Jan 11 17:22:53 CET 2018

On 01/11/2018 10:52 AM, Igor Mammedov wrote:
> On Thu, 11 Jan 2018 09:29:14 -0500
> Stefan Berger <stefanb at linux.vnet.ibm.com> wrote:
>> 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.
> I wouldn't bet on not clashing as it's a separate spec and another
> non TPM spec could use this address as well.

I don't think this would happen. I am not sure who or whether someone 
keeps track of device's addresses, but the TIS has been at that address 
for ages now and would interfer with other current and future devices.

> Laszlo's suggestion to use fwcfg file for MMIO base should take care
> in case base would need to be changed.

Linux hard coded the address. It should take it from an ACPI table as 
well, if there was a table that provided the address but since it's a 
standard address there's probably none. Ff we were to move it somewhere 
else, we'd become incompatible will all Linux versions up to now, 
something we probably don't want.

>> 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.
> if we would have hard codded address for starters, it would mean
> that layout can't be changed since old firmware /with fixed address/
> will break when address is changed on QEMU side, hence QEMU would
> have to maintain initially fixed address practically forever.

Since the PPI shared memory is not located in the ACPI stream and 
re-allocated and overwritten upon reboot, we can introduce a QEMU ACPI 
table that holds a pointer to that memory, where that pointer would be 
initialized from a constant. ACPI generating code in QEMU would also 
initialize the OperationRegion() from that constant. That way we could 
move this memory to wherever we want to in QEMU releases.

More information about the SeaBIOS mailing list