On Wed, 2024-05-01 at 12:31 -0400, Stefan Berger wrote: > > > On 5/1/24 12:21, James Bottomley wrote: > > On Tue, 2024-04-30 at 17:12 -0400, Stefan Berger wrote: > > > On 4/30/24 15:08, James Bottomley wrote: > > [...] > > > > +The mssim backend supports snapshotting and migration by not > > > > resetting > > > > > > I don't thing snapshotting is supported because snapshooting > > > would require you to be able to set the state of the vTPM from > > > the snapshot you started. I would remove the claim. > > > > I thought we established last time that it can definitely do both > > (and I've tested it because you asked me to). Snapshotting and > > migration are essentially the same thing, with snapshotting being > > easier because it can be done on the same host meaning the same > > command line parameters. If you migrate to a different host you > > need the socket to point back to the host serving the vTPM. > > > > To do this easily you simply keep the vTPM running while the VM is > > undergoing snapshot and migration. If you're thinking of and > > extended down time for the snapshot, then it's up to the vTPM > > implementation to store the state (or simply keep it running for an > > extended time doing nothing). > > Which part of the code injects the state into the vTPM so that it > resumes with the state of the TPM (PCRs, NVRAM indices, keys, > sessions etc.) from when the snapshot was taken?
We've had this conversation before too: https://lore.kernel.org/qemu-devel/f928986fd4095b1f27c83ede96f3b0dd65ad965e.ca...@linux.ibm.com/T/#u But the synopsis is nothing does. The design is to be entirely independent of vTPM implementation: it will actually work with any TPM obeying the simulator IP protocol (MS reference, ibmswtpm2 or even your swtpm) but the price of this is that the user has to preserve the vTPM state, by whatever means they deem appropriate, independently of the VM snapshot image. James
