On Thu, 28 Jun 2018 14:42:34 +0200
Marc-André Lureau <marcandre.lur...@gmail.com> wrote:
> Hi
>
> On Wed, Jun 27, 2018 at 4:26 PM, Igor Mammedov <imamm...@redhat.com> wrote:
> > On Wed, 27 Jun 2018 08:59:55 -0400
> > Stefan Berger <stef...@linux.vnet.ibm.com> wrote:
> >
> >> On 06/27/2018 08:01 AM, Igor Mammedov wrote:
> >> > On Tue, 26 Jun 2018 14:23:42 +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.
> >> >>
> >> >> 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>
> >> >>
> >> >> ---
> >> >>
> >> >> v4:
> >> >> - add ACPI only if PPI is enabled
> >> >> v3:
> >> >> - renamed to etc/tpm/config, made it static, document it
> >> >> ---
> >> >> include/hw/acpi/tpm.h | 3 +++
> >> >> hw/i386/acpi-build.c | 19 +++++++++++++++++++
> >> >> docs/specs/tpm.txt | 20 ++++++++++++++++++++
> >> >> 3 files changed, 42 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..d9320845ed 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;
> >> > is 32bit enough (what if on ARM or somewhere else area would be above
> >> > 4Gb)?
> >> > to be future proof I'd make it 64bit field so we won't have to change ABI
> >> > later on.
> >> >
> >> >> + 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,8 @@ void acpi_setup(void)
> >> >> AcpiBuildTables tables;
> >> >> AcpiBuildState *build_state;
> >> >> Object *vmgenid_dev;
> >> >> + TPMIf *tpm;
> >> >> + static FWCfgTPMConfig tpm_config;
> >> >>
> >> >> if (!pcms->fw_cfg) {
> >> >> ACPI_BUILD_DPRINTF("No fw cfg. Bailing out.\n");
> >> >> @@ -2907,6 +2915,17 @@ void acpi_setup(void)
> >> > what about vart-arm machine?
> >> > (it also has some TPM stuff but it doesn't use acpi_setup())
> >> > maybe add common helper and reuse it for both?
> >>
> >> I have never used ARM with it. I am not sure whether the firmware on ARM
> >> is instrumented to have support for PPI. If someone wanted to enable
> >> that, I would leave these parts up to them.
> >>
> >> >
> >> >
> >> >> fw_cfg_add_file(pcms->fw_cfg, ACPI_BUILD_TPMLOG_FILE,
> >> >> tables.tcpalog->data,
> >> >> acpi_data_len(tables.tcpalog));
> >> >>
> >> >> + tpm = tpm_find();
> >> >> + if (tpm && object_property_get_bool(OBJECT(tpm), "ppi",
> >> >> &error_abort)) {
> >> >> + tpm_config = (FWCfgTPMConfig) {
> >> >> + .tpmppi_address = cpu_to_le32(TPM_PPI_ADDR_BASE),
> >> >> + .tpm_version = cpu_to_le32(tpm_get_version(tpm_find())),
> >> > Have it actually been tested on big endian host?
> >>
> >> At some point I did, yes.
> >>
> >> >
> >> >> + .tpmppi_version = cpu_to_le32(TPM_PPI_VERSION_NONE)
> >> > ditto
> >> >
> >> > (that's why I don't welcome packed structures in random places)
> >>
> >> I thought a packed structure at least ensures that the offsets of the
> >> fields are agreed upon by 32 and 64bit, no ? So the firmware can use 64
> >> bit or 32bit and the offsets would be ensured.
> >
> > I think layout for this structure is:
> > 0-3 : tpmppi_address
> > 4 : tpm_version
> > 5 : tpmppi_version
> >
> > but that's not a problem,
> >
> > unit8_t foo = cpu_to_le32(bar)
> >
> > wouldn't it produce different results depending on host endianness?
>
> My understanding of C conversion from longer int to shorter ones is
> that excessive higher order bits are dropped.
>
> I think we could just remove the cpu_to_le32() call.
Yep, that should fix the bug
