Bug 1759753

Seems this is a follow-up to https://bugzilla.redhat.com/show_bug.cgi?id=1519013#c63.

I've switched this from qemu-kvm to libvirt, since any way to limit the startup should be added to the libvirt code and documentation. I also removed FutureFeature as this is more of ensuring a limitation of the existing vTPM startup/execution code.

Probably would have helped to have a better description of the defined guest environment from the source host and of course the target environment (otherwise assumptions are made determining what role migration is playing).

My assumption is qemuDomainDeviceDefValidateTPM needs to be modified so that the code can learn what to do for the _EMULATOR switch based on TPM version value. Whether TPM 1.2 will ever support PFLASH is something from bz1758153, but certainly for emulator and tpm==2.0, the def->os.loader && def->os.loader->type == VIR_DOMAIN_LOADER_TYPE_PFLASH must be true.

The https://libvirt.org/formatdomain.html#elementsTpm also should be adjusted to indicate that using TPM v2.0 emulator would require configuring/starting w/ UEFI. Add an XML example in the docs too.

I have a concern that "tpm 2.0 & uefi & CRB device" supporting status was introduced from qemu bug bz1519013. What if qemu makes changes later that it supporting more scenarios after adding limitation in libvirt or other uplayer components? Or does qemu have some API that telling libvirt which kind of vtpm is supported?
That's why I think "an earlier limitation by qemu is more close to the supporting status and more controllable".

It's not simple to limit qemu/libvirt to the "vtpm 2.0 & uefi & CRB device" combo.

It would probably be a nastly RH-specific patches to limit libvirt or qemu, and a customer could probably find work arounds the check.

However what you reported here seems like an upstream qemu bug. Imho, we should close this RH bug as WONTFIX, since the configuration isn't supported, and open an upstream bug instead.

(In reply to Marc-Andre Lureau from comment #3)

Hi Marc-Andre,

Thanks for your explanation. From what you said, is RH-specific patches a downstream only fix? You mean upstream has no statement that it doesn't support seabios+vtpm, right?
Then even the method of comment1 can be implemented, content in formatdomain.xml should not be changed since it's an upstream doc.

My bug intention is to have a limit to libvirt or qemu when guest starts. I would like to keep this bug open. Even a RH-specific patches is helpful for our customer to use vtpm as supported and avoid unnecessary wasting time.   

For the postcopy migration failure, the bug can only be filed if upstream supports seabios+vtpm. Otherwise I don't want to file a rfe bug to ask upstream to support this configuration.

Thanks.

I sent "[RHEL-AV-8.1.0 qemu-kvm PATCH] RHEL-only: limit vTPM 2.0 usage" patch for discussion/review

Feedback of the downstream-only qemu RFC patch is that it should be upstream.

But I can't justify changes in qemu upstream that aren't necessary, and would result in dead-code there.

Since it's a higher-level and rhel-only limitation, based on a particular configuration combination, I think we should revisit the idea of having this check in libvirt.

Daniel, what do you think?

(In reply to Marc-Andre Lureau from comment #6)
> Feedback of the downstream-only qemu RFC patch is that it should be upstream.
> 
> But I can't justify changes in qemu upstream that aren't necessary, and
> would result in dead-code there.

I don't read that comment as a blocker - it was just a suggestion to make it easier when we rebase in future.

> Since it's a higher-level and rhel-only limitation, based on a particular
> configuration combination, I think we should revisit the idea of having this
> check in libvirt.

Any libvirt check would be downstream only too which has the same downsides as QEMU, so this doesn't improve the situation, it just makes it someone else's problem.

The only better solution would be to not put any downstream code hacks in at all and treat the support situation as a documentation task.

The patch regarding this BZ was dropped from the queue.

Issue also reproduces for uefi guest on latest:
qemu-kvm-4.1.0-20.module+el8.1.1+5309+6d656f05.x86_64
swtpm-0.2.0-1.20191018git9227cf4.module+el8.1.1+5309+6d656f05.x86_64
libvirt-daemon-5.6.0-10.module+el8.1.1+5309+6d656f05.x86_64

#  virsh migrate rhel8.1-ovmf --live qemu+ssh://10.66.85.249/system --verbose --postcopy --postcopy-after-precopy 
error: internal error: qemu unexpectedly closed the monitor: qemu_madvise: Invalid argument
madvise doesn't support MADV_DONTDUMP, but dump_guest_core=off specified
2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range: Unaligned start address: 0x559d2afae9a0
2019-12-26T10:22:44.714892Z qemu-kvm: load of migration failed: Operation not permitted

Eventhough enable "dump_guest_core=1" in target's qemu.conf, still meet error:
#  virsh migrate rhel8.1-ovmf --live qemu+ssh://10.66.85.249/system --verbose --postcopy 
error: internal error: qemu unexpectedly closed the monitor: 2019-12-26T10:58:04.179006Z qemu-kvm: ram_block_discard_range: Unaligned start address: 0x5597964ef410
2019-12-26T10:58:04.179230Z qemu-kvm: load of migration failed: Operation not permitted


Hi John and Marc-Andre, 

Could you help confirm and move this bug from RFE to normal to fix on qemu-kvm please? 

Thank you!

Created attachment 1647741 [details]
comment10_libvirt_qemu_logs

Hi

(In reply to yanqzhan from comment #10)
> Issue also reproduces for uefi guest on latest:
> Eventhough enable "dump_guest_core=1" in target's qemu.conf, still meet
> error:
> #  virsh migrate rhel8.1-ovmf --live qemu+ssh://10.66.85.249/system
> --verbose --postcopy 
> error: internal error: qemu unexpectedly closed the monitor:
> 2019-12-26T10:58:04.179006Z qemu-kvm: ram_block_discard_range: Unaligned
> start address: 0x5597964ef410
> 2019-12-26T10:58:04.179230Z qemu-kvm: load of migration failed: Operation
> not permitted
> 
> Could you help confirm and move this bug from RFE to normal to fix on
> qemu-kvm please? 

This is a different bug. Can you confirm the same error happens without a TPM device?

(In reply to Marc-Andre Lureau from comment #12)

> This is a different bug. Can you confirm the same error happens without a
> TPM device?

Not reproduces when guest without tpm, or general migration.

Closing as WONTFIX based on Comment 6 and Comment 7. There is not a clear way to fix this.