Hi,

what is presented in the ACPI table is a "TCG Hardware Interface Description Table Format for TPM 2.0" with a TPM2 signature. I don't know if such description makes the device backward compatible with 1.2 but I would expect the TPM2.0 to be the default (that's what I tested also) and not 1.2.

From a libvirt pov what is the consequence of chosing 1.2 or 2.0: impact at qemu level or in the SW emulator? In any case if aarch64 does not properly support 1.2 qemu should return an error.

(In reply to Eric Auger from comment #1)
> Hi,
> 
> what is presented in the ACPI table is a "TCG Hardware Interface Description
> Table Format for TPM 2.0" with a TPM2 signature. I don't know if such
> description makes the device backward compatible with 1.2

According to a comment I've found in libvirt (so take it with a grain
of salt) TPM 1.2 and 2.0 are not compatible.

> but I would expect
> the TPM2.0 to be the default (that's what I tested also) and not 1.2.

The libvirt documentation[1] says that

  By default a TPM 1.2 is created.

so technically we're not doing anything wrong... Knowing this doesn't
make the current behavior any more useful though :)

> From a libvirt pov what is the consequence of chosing 1.2 or 2.0: impact at
> qemu level or in the SW emulator?

As far as I can tell, the TPM version is only used when building the
command line for swtpm, and the examples included in the QEMU
documentation[2] seem to confirm this, as they show examples of both
TPM 1.2 and 2.0 which are identical at the QEMU command line level.

Since swtpm itself seems to support TPM 1.2 on aarch64 (I think? At
the very least it doesn't look like the command fails outright, or
you'd get an error from libvirt about it) and QEMU seems to support
TPM 1.2 for tpm-tis on x86_64, is it possible that there's some
aarch64-specific code that needs to be tweaked in the frontend for
this combination to work?

Alternatively, is it possible that TPM only became a thing on ARM
after TPM 2.0 had already been standardized, and so TPM 1.2 was never
considered in the relevant specifications (ACPI etc.)?

> In any case if aarch64 does not properly
> support 1.2 qemu should return an error.

If we can determine with reasonable certainty that TPM 1.2 was never
a thing on aarch64, and is never going to be a thing either, then I
think we can build a convincing case for this configuration to be
rejected by libvirt and for the default to be changed to TPM 2.0:
this is already the case for the tpm-crb and tpm-spapr devices[3].

However, I lack the subject expertise to confidently propose such a
change... Can we perhaps dig up some references?


[1] https://libvirt.org/formatdomain.html#tpm-device
[2] https://qemu-project.gitlab.io/qemu/specs/tpm.html
[3] Yes, this means that the documentation I just referred to is
    not actually entirely accurate O:-)

Thanks Andrea for your detailed reply. I just got a reply for Ard who said that TPM1.2 is not supported at edk2 level (ArmVirtQemu). I guess at QEMU level we would also need to generate a different ACPI level. So I think we are in the case of "TPM only became a thing on ARM
after TPM 2.0 had already been standardized" and we should make libvirt default for ARM being 2.0 and document it.

Adding Marc-Andre. Marc-Andre, according to you, is it OK to set the default TPM version to 2.0 for ARM. It seems EDK2 does not support 1.2 and at qemu level the ACPI table generation may not support 1.2. I only tested 2.0 on my side. Do you know what would be the requirements in term of ACPI table (TCPA?)

I don't know the requirements for 1.2, even less on ARM. We only support vTPM 2.0 in RHEL (although 1.2 support is compiled in atm, for some historical reasons)

Hi Marc-Andre, thank you for the quick reply. So I don't see any reason supporting 1.2 on ARM and I would opt to set 2.0 by default at libvirt level for this arch.

Nevertheless, upstream I can propose a patch to fail at qemu launch if 1.2 is used.

in hw/arm/virt-acpi-build.c we have
    if (tpm_get_version(tpm_find()) == TPM_VERSION_2_0) {
        acpi_add_table(table_offsets, tables_blob);
        build_tpm2(tables_blob, tables->linker, tables->tcpalog, vms->oem_id,
                   vms->oem_table_id);
    }

Meaning that if 1.2 we do not generate any related ACPI table. I see that on i386 we generate the TCPA table. At least I can add an explicit error saying that TPM1.2 is not supported. Also this can be explictly documented at qemu level.

Patches posted upstream.

  https://listman.redhat.com/archives/libvir-list/2021-June/msg00759.html

(In reply to Andrea Bolognani from comment #7)
> Patches posted upstream.
> 
>   https://listman.redhat.com/archives/libvir-list/2021-June/msg00759.html

That works for me. Thanks!

Patches merged upstream.

  d8a1c059e0 qemu: Reject TPM 1.2 for ARM virt guests
  bf84313bbc tests: Test the defaults for TPM on ARM virt guests
  7ace0fd221 qemu: Default to TPM 2.0 for ARM virt guests
  7ad6f8dde0 tests: Add aarch64-tpm test to qemuxml2xml
  499c38b22f docs: Fix information for default TPM version

  v7.5.0-7-gd8a1c059e0

libvirt 7.6.0 will include the changes.

Verified on libvirt-7.6.0-1.module+el8.5.0+12097+2c77910b.aarch64

a) Set tpm v1.2 specifically for aarch64 guest, libvirt output an error
```
[root@hpe-moonshot-02-c25 ~]# virsh edit avocado-vt-vm1 
error: unsupported configuration: TPM 1.2 is not supported on ARM
Failed. Try again? [y,n,i,f,?]:
```
b) Don't set tpm version, libvirt use version 2 by default.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virt:av bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4684