Document that tpm-tis-device on the ARM virt machine supports PPI
with dynamically allocated MMIO via the platform bus, unlike x86
where PPI is at the fixed address 0xFED45000.
Also add hw/arm/virt-acpi-build.c and hw/acpi/tpm.c to the list
of files related to TPM ACPI tables.
Signed-off-by: Mohammadfaiz Bawa <mbawa@redhat.com>
---
docs/specs/tpm.rst | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/docs/specs/tpm.rst b/docs/specs/tpm.rst
index b630a351b4f77a8d2512f22446d00a4d674c7777..63cc0b68cd79d64138d4dd05ae158430c6a74643 100644
--- a/docs/specs/tpm.rst
+++ b/docs/specs/tpm.rst
@@ -187,8 +187,30 @@ The location of the table is given by the fw_cfg ``tpmppi_address``
field. The PPI memory region size is 0x400 (``TPM_PPI_ADDR_SIZE``) to
leave enough room for future updates.
+PPI on ARM64 virt
+-----------------
+
+The ARM virt machine supports PPI for ``tpm-tis-device`` as defined
+in the `PPI specification`_.
+
+Unlike the x86 TIS device where the PPI memory region is mapped at
+the fixed address ``0xFED45000`` (within the TIS MMIO range), the
+ARM64 sysbus device registers PPI memory as a second MMIO region
+on the platform bus. The platform bus assigns the guest physical
+address dynamically at device plug time. The ACPI ``_DSM`` method
+and PPI operation regions reference this dynamically resolved
+address.
+
+PPI is enabled by default and can be controlled with the ``ppi``
+property (e.g. ``-device tpm-tis-device,tpmdev=tpm0,ppi=on``).
+Without PPI support, guest operating systems such as Windows 11
+ARM64 will log errors when attempting to query TPM Physical
+Presence capabilities via the ACPI ``_DSM`` method.
+
QEMU files related to TPM ACPI tables:
- ``hw/i386/acpi-build.c``
+ - ``hw/arm/virt-acpi-build.c``
+ - ``hw/acpi/tpm.c``
- ``include/hw/acpi/tpm.h``
TPM backend devices
--
2.53.0On 3/24/26 3:10 AM, Mohammadfaiz Bawa wrote: > Document that tpm-tis-device on the ARM virt machine supports PPI > with dynamically allocated MMIO via the platform bus, unlike x86 > where PPI is at the fixed address 0xFED45000. > > Also add hw/arm/virt-acpi-build.c and hw/acpi/tpm.c to the list > of files related to TPM ACPI tables. > > Signed-off-by: Mohammadfaiz Bawa <mbawa@redhat.com> > --- > docs/specs/tpm.rst | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/docs/specs/tpm.rst b/docs/specs/tpm.rst > index b630a351b4f77a8d2512f22446d00a4d674c7777..63cc0b68cd79d64138d4dd05ae158430c6a74643 100644 > --- a/docs/specs/tpm.rst > +++ b/docs/specs/tpm.rst > @@ -187,8 +187,30 @@ The location of the table is given by the fw_cfg ``tpmppi_address`` > field. The PPI memory region size is 0x400 (``TPM_PPI_ADDR_SIZE``) to > leave enough room for future updates. > > +PPI on ARM64 virt > +----------------- > + > +The ARM virt machine supports PPI for ``tpm-tis-device`` as defined > +in the `PPI specification`_. > + > +Unlike the x86 TIS device where the PPI memory region is mapped at > +the fixed address ``0xFED45000`` (within the TIS MMIO range), the > +ARM64 sysbus device registers PPI memory as a second MMIO region > +on the platform bus. The platform bus assigns the guest physical > +address dynamically at device plug time. The ACPI ``_DSM`` method > +and PPI operation regions reference this dynamically resolved > +address. > + > +PPI is enabled by default and can be controlled with the ``ppi`` > +property (e.g. ``-device tpm-tis-device,tpmdev=tpm0,ppi=on``). > +Without PPI support, guest operating systems such as Windows 11 > +ARM64 will log errors when attempting to query TPM Physical > +Presence capabilities via the ACPI ``_DSM`` method. I remember having played around with TPM for QEMU on ARM64 (Raspberry 5(?)) a while ago and had the impression that there was something related to caching that prevented the MMIO interface from working correctly and Peter may have confirmed this back then on IRC .. I am not sure what exactly it was that didn't work correctly when run natively on ARM hardware. It worked well when run in CPU emulation on x86_64 for example. So I am wondering whether there is a minimum requirement for an ARM CPU or ARM CPU features related to caching that someone needs to know about to be able to use TPM TIS successfully? If so, it would probably be good to mention it here as well. If you know. Otherwise this looks good to me. > + > QEMU files related to TPM ACPI tables: > - ``hw/i386/acpi-build.c`` > + - ``hw/arm/virt-acpi-build.c`` > + - ``hw/acpi/tpm.c`` > - ``include/hw/acpi/tpm.h`` > > TPM backend devices > Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
> On 25. Mar 2026, at 20:31, Stefan Berger <stefanb@linux.ibm.com> wrote: > > > I remember having played around with TPM for QEMU on ARM64 (Raspberry 5(?)) a while ago and had the impression that there was something related to caching that prevented the MMIO interface from working correctly and Peter may have confirmed this back then on IRC .. I am not sure what exactly it was that didn't work correctly when run natively on ARM hardware. It worked well when run in CPU emulation on x86_64 for example. So I am wondering whether there is a minimum requirement for an ARM CPU or ARM CPU features related to caching that someone needs to know about to be able to use TPM TIS successfully? If so, it would probably be good to mention it here as well. If you know. > > Otherwise this looks good to me. Hi, There are two things here: - For Windows guests it’s a bit complicated Windows guests LDP accesses on the TPM register range which doesn’t match ISV=1 syndrome requirements and needs a workaround in current QEMU. I _think_ the QEMU-side workaround described below went in, which is: If we map the TPM register range as read directly, trap on write to workaround usage of LDP then we hit... - FEAT_S2FWB This is part of Armv8.4 onwards officially* and allows KVM to force a device memory type read to be promoted to write-back. That allows the (easiest) workaround for (1) to work. However that’s not the _only_ workaround, you can remove it and include https://patchew.org/QEMU/20260317174740.31674-1-lucaaamaral@gmail.com/ instead. That works fine and removes reliance on FEAT_S2FWB. * some older Arm chips implement equivalent semantics without signalling it, but that might depend on SoC-level integration. Thanks, -Mohamed
On 3/25/26 4:22 PM, Mohamed Mediouni wrote: > >> On 25. Mar 2026, at 20:31, Stefan Berger <stefanb@linux.ibm.com> wrote: >> >> >> I remember having played around with TPM for QEMU on ARM64 (Raspberry 5(?)) a while ago and had the impression that there was something related to caching that prevented the MMIO interface from working correctly and Peter may have confirmed this back then on IRC .. I am not sure what exactly it was that didn't work correctly when run natively on ARM hardware. It worked well when run in CPU emulation on x86_64 for example. So I am wondering whether there is a minimum requirement for an ARM CPU or ARM CPU features related to caching that someone needs to know about to be able to use TPM TIS successfully? If so, it would probably be good to mention it here as well. If you know. >> >> Otherwise this looks good to me. > > Hi, > > There are two things here: > > - For Windows guests it’s a bit complicated > > Windows guests LDP accesses on the TPM register range which doesn’t match ISV=1 oh, yes, right ldp instruction. > syndrome requirements and needs a workaround in current QEMU. > > I _think_ the QEMU-side workaround described below went in, which is: > > If we map the TPM register range as read directly, trap on write to workaround > usage of LDP then we hit... > > - FEAT_S2FWB > > This is part of Armv8.4 onwards officially* and allows KVM to force a device > memory type read to be promoted to write-back. > > That allows the (easiest) workaround for (1) to work. > > However that’s not the _only_ workaround, you can remove it and include > https://patchew.org/QEMU/20260317174740.31674-1-lucaaamaral@gmail.com/ instead. > > That works fine and removes reliance on FEAT_S2FWB. > > * some older Arm chips implement equivalent semantics without signalling it, but > that might depend on SoC-level integration. It would be good to mention in the docs what the user needs to know about CPU requirements, if anything, so that it can actually work. If these recent modifications/patches make the TIS work on any processor, then there's nothing to mention... > > Thanks, > -Mohamed > > >
On Thu, Mar 26, 2026 at 2:01 AM Stefan Berger <stefanb@linux.ibm.com> wrote: > > > > On 3/25/26 4:22 PM, Mohamed Mediouni wrote: > > > >> On 25. Mar 2026, at 20:31, Stefan Berger <stefanb@linux.ibm.com> wrote: > >> > >> > >> I remember having played around with TPM for QEMU on ARM64 (Raspberry 5(?)) a while ago and had the impression that there was something related to caching that prevented the MMIO interface from working correctly and Peter may have confirmed this back then on IRC .. I am not sure what exactly it was that didn't work correctly when run natively on ARM hardware. It worked well when run in CPU emulation on x86_64 for example. So I am wondering whether there is a minimum requirement for an ARM CPU or ARM CPU features related to caching that someone needs to know about to be able to use TPM TIS successfully? If so, it would probably be good to mention it here as well. If you know. > >> > >> Otherwise this looks good to me. > > > > Hi, > > > > There are two things here: > > > > - For Windows guests it’s a bit complicated > > > > Windows guests LDP accesses on the TPM register range which doesn’t match ISV=1 > > oh, yes, right ldp instruction. > > > syndrome requirements and needs a workaround in current QEMU. > > > > I _think_ the QEMU-side workaround described below went in, which is: > > > > If we map the TPM register range as read directly, trap on write to workaround > > usage of LDP then we hit... > > > > - FEAT_S2FWB > > > > This is part of Armv8.4 onwards officially* and allows KVM to force a device > > memory type read to be promoted to write-back. > > > That allows the (easiest) workaround for (1) to work. > > > > However that’s not the _only_ workaround, you can remove it and include > > https://patchew.org/QEMU/20260317174740.31674-1-lucaaamaral@gmail.com/ instead. > > > > That works fine and removes reliance on FEAT_S2FWB. > > > > * some older Arm chips implement equivalent semantics without signalling it, but > > that might depend on SoC-level integration. > > > It would be good to mention in the docs what the user needs to know > about CPU requirements, if anything, so that it can actually work. If > these recent modifications/patches make the TIS work on any processor, > then there's nothing to mention... > > > > > Thanks, > > -Mohamed > > Thanks Stefan, Mohamed I wasn't aware of the LDP / S2FWB angle, appreciate the context. Looking into it, the FEAT_S2FWB requirement is for TPM TIS MMIO access in general on ARM64 and predates this series. The PPI region we're adding is RAM-backed (memory_region_init_ram_device_ptr), so it shouldn't be affected by that issue. and for our testing we used an Ampere Altra Max M128-30 (Neoverse N1 r3p1, MIDR 0x413fd0c1). TPM TIS works correctly with Windows 11 ARM64 guests with this fix. Regards, Faiz
> On 26. Mar 2026, at 08:27, Mohammadfaiz Bawa <mbawa@redhat.com> wrote: > > On Thu, Mar 26, 2026 at 2:01 AM Stefan Berger <stefanb@linux.ibm.com> wrote: >> >> >> >> On 3/25/26 4:22 PM, Mohamed Mediouni wrote: >>> >>>> On 25. Mar 2026, at 20:31, Stefan Berger <stefanb@linux.ibm.com> wrote: >>>> >>>> >>>> I remember having played around with TPM for QEMU on ARM64 (Raspberry 5(?)) a while ago and had the impression that there was something related to caching that prevented the MMIO interface from working correctly and Peter may have confirmed this back then on IRC .. I am not sure what exactly it was that didn't work correctly when run natively on ARM hardware. It worked well when run in CPU emulation on x86_64 for example. So I am wondering whether there is a minimum requirement for an ARM CPU or ARM CPU features related to caching that someone needs to know about to be able to use TPM TIS successfully? If so, it would probably be good to mention it here as well. If you know. >>>> >>>> Otherwise this looks good to me. >>> >>> Hi, >>> >>> There are two things here: >>> >>> - For Windows guests it’s a bit complicated >>> >>> Windows guests LDP accesses on the TPM register range which doesn’t match ISV=1 >> >> oh, yes, right ldp instruction. >> >>> syndrome requirements and needs a workaround in current QEMU. >>> >>> I _think_ the QEMU-side workaround described below went in, which is: >>> >>> If we map the TPM register range as read directly, trap on write to workaround >>> usage of LDP then we hit... >>> >>> - FEAT_S2FWB >>> >>> This is part of Armv8.4 onwards officially* and allows KVM to force a device >>> memory type read to be promoted to write-back. >>>> That allows the (easiest) workaround for (1) to work. >>> >>> However that’s not the _only_ workaround, you can remove it and include >>> https://patchew.org/QEMU/20260317174740.31674-1-lucaaamaral@gmail.com/ instead. >>> >>> That works fine and removes reliance on FEAT_S2FWB. >>> >>> * some older Arm chips implement equivalent semantics without signalling it, but >>> that might depend on SoC-level integration. >> >> >> It would be good to mention in the docs what the user needs to know >> about CPU requirements, if anything, so that it can actually work. If >> these recent modifications/patches make the TIS work on any processor, >> then there's nothing to mention... >> >>> >>> Thanks, >>> -Mohamed >>> > > Thanks Stefan, Mohamed > > I wasn't aware of the LDP / S2FWB angle, appreciate the context. > Hello, > Looking into it, the FEAT_S2FWB requirement is for TPM TIS MMIO access > in general on ARM64 and predates this series. Yes, it was added as a workaround for baseline Windows support. > The PPI region we're > adding is RAM-backed (memory_region_init_ram_device_ptr), so it > shouldn't be affected by that issue. FEAT_S2FWB is for the case where the guest tries to access as MMIO while the memory region is RAM-backed. From a quick look at the Linux kernel driver it does a devm_ioremap_resource which assumes MMIO in drivers/char/tpm/tpm_tis.c Hence relying (further) on FEAT_S2FWB. > and for our testing we used an Ampere Altra Max M128-30 (Neoverse N1 > r3p1, MIDR 0x413fd0c1). Neoverse N1 systems with the Arm CMN fabric aren’t exactly the right system to test this. They don’t advertise FEAT_S2FWB but technically have equivalent semantics. Once the ISV = 0 syndrome support patches get in, there’ll be a nicer way than relying on undocumented support for those semantics or relying on FEAT_S2FWB without querying it, by switching those away from RAM-backed to an MMIO trap. Thanks, -Mohamed
On Thu, Mar 26, 2026 at 4:59 PM Mohamed Mediouni <mohamed@unpredictable.fr> wrote: > > > > On 26. Mar 2026, at 08:27, Mohammadfaiz Bawa <mbawa@redhat.com> wrote: > > > > On Thu, Mar 26, 2026 at 2:01 AM Stefan Berger <stefanb@linux.ibm.com> wrote: > >> > >> > >> > >> On 3/25/26 4:22 PM, Mohamed Mediouni wrote: > >>> > >>>> On 25. Mar 2026, at 20:31, Stefan Berger <stefanb@linux.ibm.com> wrote: > >>>> > >>>> > >>>> I remember having played around with TPM for QEMU on ARM64 (Raspberry 5(?)) a while ago and had the impression that there was something related to caching that prevented the MMIO interface from working correctly and Peter may have confirmed this back then on IRC .. I am not sure what exactly it was that didn't work correctly when run natively on ARM hardware. It worked well when run in CPU emulation on x86_64 for example. So I am wondering whether there is a minimum requirement for an ARM CPU or ARM CPU features related to caching that someone needs to know about to be able to use TPM TIS successfully? If so, it would probably be good to mention it here as well. If you know. > >>>> > >>>> Otherwise this looks good to me. > >>> > >>> Hi, > >>> > >>> There are two things here: > >>> > >>> - For Windows guests it’s a bit complicated > >>> > >>> Windows guests LDP accesses on the TPM register range which doesn’t match ISV=1 > >> > >> oh, yes, right ldp instruction. > >> > >>> syndrome requirements and needs a workaround in current QEMU. > >>> > >>> I _think_ the QEMU-side workaround described below went in, which is: > >>> > >>> If we map the TPM register range as read directly, trap on write to workaround > >>> usage of LDP then we hit... > >>> > >>> - FEAT_S2FWB > >>> > >>> This is part of Armv8.4 onwards officially* and allows KVM to force a device > >>> memory type read to be promoted to write-back. > >>>> That allows the (easiest) workaround for (1) to work. > >>> > >>> However that’s not the _only_ workaround, you can remove it and include > >>> https://patchew.org/QEMU/20260317174740.31674-1-lucaaamaral@gmail.com/ instead. > >>> > >>> That works fine and removes reliance on FEAT_S2FWB. > >>> > >>> * some older Arm chips implement equivalent semantics without signalling it, but > >>> that might depend on SoC-level integration. > >> > >> > >> It would be good to mention in the docs what the user needs to know > >> about CPU requirements, if anything, so that it can actually work. If > >> these recent modifications/patches make the TIS work on any processor, > >> then there's nothing to mention... > >> > >>> > >>> Thanks, > >>> -Mohamed > >>> > > > > Thanks Stefan, Mohamed > > > > I wasn't aware of the LDP / S2FWB angle, appreciate the context. > > > Hello, > > > Looking into it, the FEAT_S2FWB requirement is for TPM TIS MMIO access > > in general on ARM64 and predates this series. > > Yes, it was added as a workaround for baseline Windows support. > > > The PPI region we're > > adding is RAM-backed (memory_region_init_ram_device_ptr), so it > > shouldn't be affected by that issue. > > FEAT_S2FWB is for the case where the guest tries to access as MMIO > while the memory region is RAM-backed. > > From a quick look at the Linux kernel driver it does a > devm_ioremap_resource which assumes MMIO in drivers/char/tpm/tpm_tis.c > > Hence relying (further) on FEAT_S2FWB. > that makes sense I was thinking about it from the host side. > > and for our testing we used an Ampere Altra Max M128-30 (Neoverse N1 > > r3p1, MIDR 0x413fd0c1). > > Neoverse N1 systems with the Arm CMN fabric aren’t exactly the right > system to test this. They don’t advertise FEAT_S2FWB but technically > have equivalent semantics. > > Once the ISV = 0 syndrome support patches get in, there’ll be a nicer > way than relying on undocumented support for those semantics or relying > on FEAT_S2FWB without querying it, by switching those away from RAM-backed > to an MMIO trap. > > Thanks, > -Mohamed > > For v2, I see a few options for the docs and wanted to get your take: -Add a note in the PPI section mentioning the FEAT_S2FWB requirement for TPM TIS on ARM64 -Add it as a separate general "TPM TIS on ARM64" note since the requirement predates PPI and applies to the TIS MMIO region as a whole -Hold off until the ISV=0 syndrome support patches land, since they'd remove the FEAT_S2FWB dependency and make any note we add now outdated I'm also testing on additional hardware - Marvell ThunderX2 (Armv8.1, no FEAT_S2FWB) and Nvidia Grace (Neoverse V2, Armv9, has FEAT_S2FWB) -- to get proper coverage across the spectrum. Happy to report results.
On Fri, 27 Mar 2026 at 10:08, Mohammadfaiz Bawa <mbawa@redhat.com> wrote: > For v2, I see a few options for the docs and wanted to get your take: > > -Add a note in the PPI section mentioning the FEAT_S2FWB requirement > for TPM TIS on ARM64 > -Add it as a separate general "TPM TIS on ARM64" note since the > requirement predates PPI and applies to the TIS MMIO region as a whole > -Hold off until the ISV=0 syndrome support patches land, since they'd > remove the FEAT_S2FWB dependency and make any note we add now outdated We could in theory have QEMU check for whether the host has FEAT_S2FWB and actively warn/error about enabling the TPM in that setup. But if we're going to land ISV=0 emulation soon that might not be worth the effort. -- PMM
On Fri, Mar 27, 2026 at 3:56 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Fri, 27 Mar 2026 at 10:08, Mohammadfaiz Bawa <mbawa@redhat.com> wrote: > > For v2, I see a few options for the docs and wanted to get your take: > > > > -Add a note in the PPI section mentioning the FEAT_S2FWB requirement > > for TPM TIS on ARM64 > > -Add it as a separate general "TPM TIS on ARM64" note since the > > requirement predates PPI and applies to the TIS MMIO region as a whole > > -Hold off until the ISV=0 syndrome support patches land, since they'd > > remove the FEAT_S2FWB dependency and make any note we add now outdated > > We could in theory have QEMU check for whether the host has > FEAT_S2FWB and actively warn/error about enabling the TPM > in that setup. But if we're going to land ISV=0 emulation soon > that might not be worth the effort. > > -- PMM > Thanks, Peter. Agreed no point adding a runtime check if ISV=0 emulation is around the corner. I went ahead and tested across a few different ARM64 hosts to get a clearer picture: *Nvidia Grace (Neoverse V2, Armv9) - Win11 ARM64 installed cleanly, no Event ID 15. This one has FEAT_S2FWB. *Ampere Altra Max (Neoverse N1, Armv8.2) - Also works fine. N1 doesn't advertise FEAT_S2FWB but has equivalent semantics as Mohamed mentioned. *Marvell ThunderX2 (CN9980, Armv8.1) - Hangs in TianoCore as soon as TPM is enabled. Boots fine without TPM. This is Armv8.1 with no FEAT_S2FWB at all. So the ThunderX2 result confirms exactly what Mohamed described - TPM TIS MMIO needs FEAT_S2FWB (or equivalent) on the host. The PPI patches don't change that requirement. Will send v2 shortly with the doc hunk move Stefan asked for. Thanks, Faiz
© 2016 - 2026 Red Hat, Inc.