Bitlocker-tripping hardware change with 5.2.0?

[Michael Weiser]

Hello,

I have a Windows 10 with BitLocker activated running happily in
libvirtd/virt-manager.

After upgrading to qemu 5.2.0 it refuses to boot and presents a screen
with blue background where Bitlocker explains that the hardware
configuration has changed and I need to enter a recovery key.
Going back to 5.1.0 makes it boot again.

Is this expected behaviour?
How can I figure out what trips Bitlocker?

I was expecting to work around this kind of issue by using a VM and
keeping the virtualised hardware stable (e.g. -machine pc-q35-5.1).

IIRC I needed to activate swtpm in TIS and version 1.2 mode by trial and
error because that was the only combo that worked for Bitlocker. The
machine runs in BIOS mode and thus without SecureBoot because I wanted
internal snapshots to work.

I have extracted and simplified the qemu command from libvirtd somewhat
and can reproduce the issue while running swtpm manually.

I have verified the behaviour with a freshly installed Windows 10 and
qemu 5.2.0 and today's git HEAD compiled from source.

The following exact same commands have the machine booting when using
qemu 5.1.0 and end up in the Bitlocker recovery screen when using 5.2.0
or git HEAD:

/usr/bin/swtpm socket
--ctrl type=unixio,path=11-win10-bitlocker-swtpm.sock,mode=0600
--tpmstate dir=bf566263-35e3-4dba-af8c-8ca85dba6a85/tpm1.2,mode=0600

qemu-system-x86_64 -machine pc-q35-5.1 -m 4096
-uuid bf566263-35e3-4dba-af8c-8ca85dba6a85 -no-user-config
-blockdev 
'{"driver":"file","filename":"win10-bitlocker.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}'
-blockdev 
'{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null}'
-device ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1
-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm
-chardev socket,id=chrtpm,path=11-win10-bitlocker-swtpm.sock
-device tpm-tis,tpmdev=tpm-tpm0,id=tpm0

This appears to be the minimum set of options. Any change to any of them
and the machine won't boot with 5.1.0 either.
-- 
Thanks,
Michael