Hi
On Mon, Jun 25, 2018 at 5:20 PM, Laszlo Ersek <ler...@redhat.com> wrote:
> On 06/21/18 12:10, Marc-André Lureau wrote:
>> Hi
>>
>> On Thu, Jun 21, 2018 at 12:00 PM, Igor Mammedov <imamm...@redhat.com> wrote:
>>> On Tue, 15 May 2018 14:14:31 +0200
>>> Marc-André Lureau <marcandre.lur...@redhat.com> wrote:
>>>
>>>> From: Stefan Berger <stef...@linux.vnet.ibm.com>
>>>>
>>>> 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 <stef...@linux.vnet.ibm.com>
>>>> [ Marc-André: renamed to etc/tpm/config, made it static, document it ]
>>>> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
>>>> ---
>>>> 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. 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
>>>
>>>
>>
>>
>>
>
--
Marc-André Lureau
