On Sun, Mar 06, 2022 at 04:47:58PM +0000, Etienne Dechamps wrote: > Package: ovmf > Version: 2022.02-1 > Severity: important > Control: fixed -1 2021.11-1 > > An ovmf regression somewhere between 2021.11-1 and 2022.02-1 makes it > impossible to use a TPM in Windows guest VMs (tested with various > Windows 11 builds). The Windows Device Manager shows the TPM as > defective, with the error "This device cannot start. (Code 10) A > protocol error was detected between the driver and the device". > tpm.msc shows no TPM is available. > > One consequence is that Windows 11 refuses to install with ovmf > 2022.02-1, since the Windows 11 installer demands a functional TPM. > > Steps to reproduce using qemu-system-x86 1:6.2+dfsg-2 and swtpm 0.7.1-1: > > # mkdir /tmp/tpm > # swtpm socket --tpm2 --tpmstate dir=/tmp/tpm --ctrl > type=unixio,path=/tmp/tpm/sock & > # qemu-system-x86_64 -enable-kvm -drive > if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd > -chardev socket,id=tpm,path=/tmp/tpm/sock -tpmdev > emulator,id=tpm,chardev=tpm -device tpm-tis,tpmdev=tpm … > > With ovmf 2021.11-1, the TPM is functional in Windows using the above > parameters; with 2022.02-1, it is not. Switching to "tpm-crb" doesn't > seem to make any difference. > > In Linux guests the TPM appears to be functional, although the guest > kernel outputs the following messages with 2022.02-1: > > tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1, rev-id 1) > tpm tpm0: A TPM error (256) occurred attempting the self test > tpm tpm0: starting up the TPM manually > > With 2021.11-1, the kernel only outputs the first line - no errors.
Thanks for the bug report. Apparently upstream renamed the flag to enable the TPM, so we need to adjust the build: https://github.com/tianocore/edk2/commit/4de8d61bcec02a13ceed84f92b0cf3ea58adf9c5 -dann
