TPM 1.2 is a pretty bad default these days, especially for
architectures which were introduced when TPM 2.0 already existed.
We're already carving out exceptions for several scenarios, but
that's basically backwards: at this point, using TPM 1.2 is the
exception.
Restructure the code so that it reflects reality and we don't
have to remember to update it every time a new architecture is
introduced.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We have a non-trivial amount of architecture-specific logic
dealing with TPM, so it's good to have coverage for it.
Note that two architectures currently don't have support for
TPM devices enabled by default in QEMU: loongarch64 and s390x.
The situation might change for the former, but that's unlikely
to happen for the latter.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
These are similar to the minimal cases that we just introduced,
but are intended to demonstrate what device or controller model
libvirt will choose when one is not provided by the user.
Note that we want both regular and ABI_UPDATE variants of the
various test cases because, in some cases, the behavior for new
guests is not the same as that for existing ones due to backward
compatibility concerns.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
