Re: [Qemu-devel] [PATCH v3 2/4] acpi: add fw_cfg file for TPM and PPI virtual memory device

[Laszlo Ersek]

On 06/26/18 12:38, Marc-André Lureau wrote:
> Hi
> 
> On Mon, Jun 25, 2018 at 5:20 PM, Laszlo Ersek <address@hidden> wrote:
>> On 06/21/18 12:10, Marc-André Lureau wrote:
>>> Hi
>>>
>>> On Thu, Jun 21, 2018 at 12:00 PM, Igor Mammedov <address@hidden> wrote:
>>>> On Tue, 15 May 2018 14:14:31 +0200
>>>> Marc-André Lureau <address@hidden> wrote:
>>>>
>>>>> From: Stefan Berger <address@hidden>
>>>>>
>>>>> To avoid having to hard code the base address of the PPI virtual
>>>>> memory device we introduce a fw_cfg file etc/tpm/config that holds the
>>>>> base address of the PPI device, the version of the PPI interface and
>>>>> the version of the attached TPM.
>>>> is it related to TPM_PPI_ADDR_BASE added in previous patch?
>>>>
>>>>>
>>>>> Signed-off-by: Stefan Berger <address@hidden>
>>>>> [ Marc-André: renamed to etc/tpm/config, made it static, document it ]
>>>>> Signed-off-by: Marc-André Lureau <address@hidden>
>>>>> ---
>>>>>  include/hw/acpi/tpm.h |  3 +++
>>>>>  hw/i386/acpi-build.c  | 17 +++++++++++++++++
>>>>>  docs/specs/tpm.txt    | 20 ++++++++++++++++++++
>>>>>  3 files changed, 40 insertions(+)
>>>>>
>>>>> diff --git a/include/hw/acpi/tpm.h b/include/hw/acpi/tpm.h
>>>>> index c082df7d1d..f79d68a77a 100644
>>>>> --- a/include/hw/acpi/tpm.h
>>>>> +++ b/include/hw/acpi/tpm.h
>>>>> @@ -193,4 +193,7 @@ REG32(CRB_DATA_BUFFER, 0x80)
>>>>>  #define TPM_PPI_ADDR_SIZE           0x400
>>>>>  #define TPM_PPI_ADDR_BASE           0xFED45000
>>>>>
>>>>> +#define TPM_PPI_VERSION_NONE        0
>>>>> +#define TPM_PPI_VERSION_1_30        1
>>>>> +
>>>>>  #endif /* HW_ACPI_TPM_H */
>>>>> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>>>>> index 9bc6d97ea1..f6d447f03a 100644
>>>>> --- a/hw/i386/acpi-build.c
>>>>> +++ b/hw/i386/acpi-build.c
>>>>> @@ -119,6 +119,12 @@ typedef struct AcpiBuildPciBusHotplugState {
>>>>>      bool pcihp_bridge_en;
>>>>>  } AcpiBuildPciBusHotplugState;
>>>>>
>>>>> +typedef struct FWCfgTPMConfig {
>>>>> +    uint32_t tpmppi_address;
>>>>> +    uint8_t tpm_version;
>>>>> +    uint8_t tpmppi_version;
>>>>> +} QEMU_PACKED FWCfgTPMConfig;
>>>>> +
>>>>>  static void init_common_fadt_data(Object *o, AcpiFadtData *data)
>>>>>  {
>>>>>      uint32_t io = object_property_get_uint(o, ACPI_PM_PROP_PM_IO_BASE, 
>>>>> NULL);
>>>>> @@ -2873,6 +2879,7 @@ void acpi_setup(void)
>>>>>      AcpiBuildTables tables;
>>>>>      AcpiBuildState *build_state;
>>>>>      Object *vmgenid_dev;
>>>>> +    static FWCfgTPMConfig tpm_config;
>>>>>
>>>>>      if (!pcms->fw_cfg) {
>>>>>          ACPI_BUILD_DPRINTF("No fw cfg. Bailing out.\n");
>>>>> @@ -2907,6 +2914,16 @@ void acpi_setup(void)
>>>>>      fw_cfg_add_file(pcms->fw_cfg, ACPI_BUILD_TPMLOG_FILE,
>>>>>                      tables.tcpalog->data, acpi_data_len(tables.tcpalog));
>>>>>
>>>>> +    if (tpm_find()) {
>>>>> +        tpm_config = (FWCfgTPMConfig) {
>>>>> +            .tpmppi_address = cpu_to_le32(TPM_PPI_ADDR_BASE),
>>>>> +            .tpm_version = cpu_to_le32(tpm_get_version(tpm_find())),
>>>>> +            .tpmppi_version = cpu_to_le32(TPM_PPI_VERSION_NONE)
>>>>> +        };
>>>>> +        fw_cfg_add_file(pcms->fw_cfg, "etc/tpm/config",
>>>>> +                        &tpm_config, sizeof tpm_config);
>>>>> +    }
>>>> why it's in ACPI part of the code, shouldn't it be a part of device,
>>>> could TPM be used without ACPI at all (-noacpi CLI option)?
>>>>
>>>> Wouldn't adding fwcfg entry unconditionally break migration?
>>>
>>> Because of unstable entry IDs? that could be problematic. (especially
>>> during boot time) What do you think Laszlo?
>>>
>>> I guess we could have a "ppi" device property, that would imply having
>>> the etc/tpm/config fw_cfg entry. We would enable it by default in
>>> newer machine types (3.0?)
>>
>> Can we perhaps draw a parallel with "-device vmcoreinfo" here? For that
>> device model, fw_cfg_add_file_callback() is called in the realize
>> function, vmcoreinfo_realize(). If libvirt generates the identical
>> cmdline on both ends of the migration, and uses the same machine type, I
>> think the fw_cfg selectors should end up the same on both sides.
> 
> -device vmcoreinfo is a  standalone fw-cfg entry. PPI is tied to a
> TPM, the fw-cfg entry is an implementation detail between qemu and
> firmware. So I prefer the "ppi" device property.

Ah, right, sorry I got confused for a moment. The TPM device makes sense
without the (optional) Physical Presence Interface too.

Thanks,
Laszlo

> Wrt to migration,
> that should be equivalent to -device vmcoreinfo (except that -device
> vmcoreinfo is not enabled by default in newer machine types)
> 
>> Thanks
>> Laszlo
>>
>>>>
>>>>> +
>>>>>      vmgenid_dev = find_vmgenid_dev();
>>>>>      if (vmgenid_dev) {
>>>>>          vmgenid_add_fw_cfg(VMGENID(vmgenid_dev), pcms->fw_cfg,
>>>>> diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt
>>>>> index c230c4c93e..2ddb768084 100644
>>>>> --- a/docs/specs/tpm.txt
>>>>> +++ b/docs/specs/tpm.txt
>>>>> @@ -20,6 +20,26 @@ QEMU files related to TPM TIS interface:
>>>>>   - hw/tpm/tpm_tis.h
>>>>>
>>>>>
>>>>> += fw_cfg interface =
>>>>> +
>>>>> +The bios/firmware may use the "etc/tpm/config" fw_cfg entry for
>>>>> +configuring the guest appropriately.
>>>>> +
>>>>> +The entry of 6 bytes has the following content, in little-endian:
>>>>> +
>>>>> +    #define TPM_VERSION_UNSPEC          0
>>>>> +    #define TPM_VERSION_1_2             1
>>>>> +    #define TPM_VERSION_2_0             2
>>>>> +
>>>>> +    #define TPM_PPI_VERSION_NONE        0
>>>>> +    #define TPM_PPI_VERSION_1_30        1
>>>>> +
>>>>> +    struct FWCfgTPMConfig {
>>>>> +        uint32_t tpmppi_address;         /* PPI memory location */
>>>>> +        uint8_t tpm_version;             /* TPM version */
>>>>> +        uint8_t tpmppi_version;          /* PPI version */
>>>>> +    };
>>>>> +
>>>>>  = ACPI Interface =
>>>>>
>>>>>  The TPM device is defined with ACPI ID "PNP0C31". QEMU builds a SSDT and 
>>>>> passes
>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 
>