From: Stefan Berger <stefanb@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.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
[ Marc-André: renamed to etc/tpm/config, made it static, document it ]
Signed-off-by: Marc-André Lureau <marcandre.lureau@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);
+ }
+
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
--
2.17.0.253.g3dd125b46d
On Tue, 15 May 2018 14:14:31 +0200
Marc-André Lureau <marcandre.lureau@redhat.com> wrote:
> From: Stefan Berger <stefanb@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 <stefanb@linux.vnet.ibm.com>
> [ Marc-André: renamed to etc/tpm/config, made it static, document it ]
> Signed-off-by: Marc-André Lureau <marcandre.lureau@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?
> +
> 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
Hi
On Thu, Jun 21, 2018 at 12:00 PM, Igor Mammedov <imammedo@redhat.com> wrote:
> On Tue, 15 May 2018 14:14:31 +0200
> Marc-André Lureau <marcandre.lureau@redhat.com> wrote:
>
>> From: Stefan Berger <stefanb@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 <stefanb@linux.vnet.ibm.com>
>> [ Marc-André: renamed to etc/tpm/config, made it static, document it ]
>> Signed-off-by: Marc-André Lureau <marcandre.lureau@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?)
>
>> +
>> 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
On Thu, 21 Jun 2018 12:10:32 +0200
Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
> Hi
>
> On Thu, Jun 21, 2018 at 12:00 PM, Igor Mammedov <imammedo@redhat.com> wrote:
> > On Tue, 15 May 2018 14:14:31 +0200
> > Marc-André Lureau <marcandre.lureau@redhat.com> wrote:
> >
> >> From: Stefan Berger <stefanb@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 <stefanb@linux.vnet.ibm.com>
> >> [ Marc-André: renamed to etc/tpm/config, made it static, document it ]
> >> Signed-off-by: Marc-André Lureau <marcandre.lureau@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?)
yep, something like this.
usual practice is to enable it by default and disable it for old
machine types using hw compat props (include/hw/compat.h)
>
> >
> >> +
> >> 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
> >
> >
>
>
>
On 06/21/18 12:10, Marc-André Lureau wrote: > What do you think Laszlo? Apologies, I'm currently lacking the bandwidth to even understand the question. I'm tagging this message for later; it'll take a while before I get to it. Thanks Laszlo
On 06/21/18 12:10, Marc-André Lureau wrote:
> Hi
>
> On Thu, Jun 21, 2018 at 12:00 PM, Igor Mammedov <imammedo@redhat.com> wrote:
>> On Tue, 15 May 2018 14:14:31 +0200
>> Marc-André Lureau <marcandre.lureau@redhat.com> wrote:
>>
>>> From: Stefan Berger <stefanb@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 <stefanb@linux.vnet.ibm.com>
>>> [ Marc-André: renamed to etc/tpm/config, made it static, document it ]
>>> Signed-off-by: Marc-André Lureau <marcandre.lureau@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.
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
>>
>>
>
>
>
Hi
On Mon, Jun 25, 2018 at 5:20 PM, Laszlo Ersek <lersek@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 <imammedo@redhat.com> wrote:
>>> On Tue, 15 May 2018 14:14:31 +0200
>>> Marc-André Lureau <marcandre.lureau@redhat.com> wrote:
>>>
>>>> From: Stefan Berger <stefanb@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 <stefanb@linux.vnet.ibm.com>
>>>> [ Marc-André: renamed to etc/tpm/config, made it static, document it ]
>>>> Signed-off-by: Marc-André Lureau <marcandre.lureau@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
On 06/26/18 12:38, Marc-André Lureau wrote:
> Hi
>
> On Mon, Jun 25, 2018 at 5:20 PM, Laszlo Ersek <lersek@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 <imammedo@redhat.com> wrote:
>>>> On Tue, 15 May 2018 14:14:31 +0200
>>>> Marc-André Lureau <marcandre.lureau@redhat.com> wrote:
>>>>
>>>>> From: Stefan Berger <stefanb@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 <stefanb@linux.vnet.ibm.com>
>>>>> [ Marc-André: renamed to etc/tpm/config, made it static, document it ]
>>>>> Signed-off-by: Marc-André Lureau <marcandre.lureau@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.
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
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
© 2016 - 2026 Red Hat, Inc.