From: Igor Mammedov <imammedo@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: Laszlo Ersek <lersek@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Stefan Berger <stefanb@linux.vnet.ibm.com>,
QEMU <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v3 2/4] acpi: add fw_cfg file for TPM and PPI virtual memory device
Date: Thu, 21 Jun 2018 15:55:11 +0200 [thread overview]
Message-ID: <20180621155511.1fe61df5@redhat.com> (raw)
In-Reply-To: <CAJ+F1CLYvrddKXdVfqa-Jiw-jr2LrxUbznW4Tn6kDK+O3J-M9Q@mail.gmail.com>
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
> >
> >
>
>
>
next prev parent reply other threads:[~2018-06-21 13:55 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 12:14 [Qemu-devel] [PATCH v3 0/4] Add support for TPM Physical Presence interface Marc-André Lureau
2018-05-15 12:14 ` [Qemu-devel] [PATCH v3 1/4] tpm: implement virtual memory device for TPM PPI Marc-André Lureau
2018-05-15 14:19 ` Stefan Berger
2018-06-21 9:49 ` Igor Mammedov
2018-06-21 10:51 ` Marc-André Lureau
2018-06-21 13:59 ` Igor Mammedov
2018-05-15 12:14 ` [Qemu-devel] [PATCH v3 2/4] acpi: add fw_cfg file for TPM and PPI virtual memory device Marc-André Lureau
2018-06-21 10:00 ` Igor Mammedov
2018-06-21 10:10 ` Marc-André Lureau
2018-06-21 13:55 ` Igor Mammedov [this message]
2018-06-22 0:16 ` Laszlo Ersek
2018-06-25 15:20 ` Laszlo Ersek
2018-06-26 10:38 ` Marc-André Lureau
2018-06-26 10:54 ` Laszlo Ersek
2018-05-15 12:14 ` [Qemu-devel] [PATCH v3 3/4] acpi: build TPM Physical Presence interface Marc-André Lureau
2018-06-20 14:08 ` Michael S. Tsirkin
2018-06-20 14:35 ` Marc-André Lureau
2018-06-20 15:08 ` Laszlo Ersek
2018-06-20 15:31 ` Michael S. Tsirkin
2018-06-20 16:37 ` Stefan Berger
2018-06-21 12:54 ` Igor Mammedov
2018-06-21 13:21 ` Marc-André Lureau
2018-06-21 13:22 ` Marc-André Lureau
2018-06-21 14:13 ` Marc-André Lureau
2018-06-21 14:27 ` Igor Mammedov
2018-06-21 13:48 ` Stefan Berger
2018-06-21 14:23 ` Igor Mammedov
2018-06-21 17:10 ` Marc-André Lureau
2018-06-21 17:36 ` Stefan Berger
2018-06-22 13:40 ` Igor Mammedov
2018-05-15 12:14 ` [Qemu-devel] [PATCH v3 4/4] tpm: add a fake ACPI memory clear interface Marc-André Lureau
2018-06-21 13:02 ` Igor Mammedov
2018-06-21 13:24 ` Marc-André Lureau
2018-06-21 13:59 ` Stefan Berger
2018-06-21 14:33 ` Igor Mammedov
2018-06-26 9:22 ` Marc-André Lureau
2018-06-26 12:34 ` Igor Mammedov
2018-06-26 12:47 ` Laszlo Ersek
2018-06-26 15:22 ` Stefan Berger
2018-06-20 13:11 ` [Qemu-devel] [PATCH v3 0/4] Add support for TPM Physical Presence interface Marc-André Lureau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180621155511.1fe61df5@redhat.com \
--to=imammedo@redhat.com \
--cc=ehabkost@redhat.com \
--cc=lersek@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=stefanb@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).