CP-39414: start swtpm depending on the VM's platform metadata

[psafont]

Now swtpm is only started for domains that have vtpm=true added to their
platform's metada. This can be done using xe e.g.
xe vm-param-add uuid=VM-XXX param-name=platform vtpm=true

Shutting down domains without the swtpm and the xapi-guard services
running works as normal and without any errorsNow swtpm is only started for domains that have vtpm=true added to their
platform's metada. This can be done using xe e.g.
xe vm-param-add uuid=VM-XXX param-name=platform vtpm=true

Shutting down domains without the swtpm and the xapi-guard services
running works as normal and without any errors.

[edwintorok]

I think we should create a vTPM object when vtpm=true, and then start/stop the vtpm daemon based on the presence of the vtpm object (fairly soon we'll need to write out and give access to the vTPM object, so we'll need to know its UUID/ref). Might need a bit more plumbing, see how the bios vs uefi is done in xenops_types firmware_type.
Do we also want to define a 'module VTPM' in device.ml?

[psafont]

I think we should create a vTPM object when vtpm=true

I believe this needs to happen when trying to start the VM

start/stop the vtpm daemon based on the presence of the vtpm object

For starting I agree, I'd say it's part of object creation. For stopping it happens unconditionally, the code checks whether the swtpm process exists or not. We wouldn't want a case where the obkect has been removed but somehow the swtpm process is still running.

(fairly soon we'll need to write out and give access to the vTPM object, so we'll need to know its UUID/ref). Might need a bit more plumbing, see how the bios vs uefi is done in xenops_types firmware_type.

I'll check this. I think it's worth noting that currently a tpm instance is closely coupled with a vm instance. For the future it might be worth decoupling it and using the vtpm uuid as you say.

Do we also want to define a 'module VTPM' in device.ml?

Not sure I follow, the swtpm daemon already has a module in device.ml

[psafont]

Now an optional variant is passed through the idl so all the logic to decide what information gets passed around can be done in xapi. Xenopsd can decide how to set up swtpm based on that information.

This should make creating the vtpm object and changing how to set up swtpm much simpler

[psafont]

I've tested that xapi now creates and destroys the vtpm objects on a VM's first boot (not on successive boots) and when they are destroyed.